Messages in this thread | | | From | "Peter T. Breuer" <> | Subject | re: yoke device driver | Date | Sun, 28 Nov 1999 00:31:24 +0100 (MET) |
| |
OK .. I've put up a version for 2.2.* now on
http://www.it.uc3m.es/~ptb/cgi-bin/cvs-yoke.cgi ftp://oboe.it.uc3m.es/pub/Programs/yoke-0.2.4.tgz
"Peter T. Breuer wrote:" > I've been writing a "yoke" device driver - it hooks up several block > devices into a single device. Like a mirror but with many faces. Write > to any of the yoked devices and you write in all of them.
I still need help with some issues. To make things easier on myself I borrowed the loop.c and have been yoking loopback devices together since I can now control the code exactly. Scsi and IDE is too complicated to develop against. But be sure to use the loop.c I provided ...
The device can "hot-swap" mirror components, since it's just a binding, not a real device. It's intended to act as a node in a networked topology, eventually. This is what is supposed to happen:
The existing code demonstrates that the concept of stealing the yoked block devices request_fn works.
We substitute our own, like a cuckoo. When a block device tries to treat its accumulating requests, it executes our cuckoo function.
This works ... our function marks the individual buffer heads by putting in a special end_io() function into their b_end_io fields, and that's another cuckoo. Then it runs the original device request_fn so that nobody will spot anything.
When the kernel has treated the requests, the default end_request function runs the end_io function in the buffer_head, and thus hands back control to us. Instead of freeing up the buffer, we retarget the buffer head as necessary and resubmit it as a new request, thus doing mirroring. When we get the buffer head back for the umpteenth time, then we finish up the buffer i/o as originally intended.
Outstanding problems:
1.It seems to sometimes hang on read just now. Don't know why. Bug. 2.I don't really know exactly what is needed to make the buffers commit themselves just before I retarget the buffer heads. Should I do a wait_on_buffer to keep them marked? Which incantantations should I be using on buffers ... help! 3.I don't know how to handle devices that do plugging. Minor issue. 4.I need a way of invalidating buffers in the kernel cache that might obscure the block I just wrote into a mirrored device! Help 5.If retargetting doesn't work, and it should, then I will go to copying (yecch), as in RAID.
Would appreciate fixes for 2 and 4 above.
Peter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |