lkml.org 
[lkml]   [1999]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subjectre: yoke device driver
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.037 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site