[ENBD] proxing ioctl's

[Peter T. Breuer]

OK Daniel ..

> It looks like a 4 or 5 lines of code max to implement client 
> side journaling. I even think it would be more efficient that
> the current solution. 

I have something that works, but I don't fully see why.

Now .. it is my impression that in 2.4.0, requests are dropping through
to the driver layer even if they can be satisfied by VFS. So, taking
that as a given, it is the drivers duty to react accordingly. But
how does it know that the request is "one of those"?

What I am doing in order to cache on write is what the rd.c driver does
... call getblk() for a new bh, copy every bh of the request in there,
set their protected bit and brelse them, then call endio on the bh's of
the original request via the standard end_request fn. As far as I can
tell, this works. A second write over the same area clearly gets 
all its bh's out of the cache, so they must have been in there. I
am "telling" by "is original bh == blkdev(bh->rsector*2)" (approx).

I.e. I am looking to see if the bh returned by getblk is the one I
already have, in which case the bh I have must have come from the cache
too.

On read, I am somewhat fazed. I've tried the same technique of
going through the bh's of the request one by one and calling getblk on
them. If the result is the  same, then it came from the cache, and
so I THINk the request bh has already been satisfied from the VFS.

In that case, I am not calling end_io on the bh. I am not
removing it from the request. I am not doing anything else but the 
normal queuing of the request to the driver. I am puzzled as to why
I apparently don't have to any of these things, because apparently
everything still works as it should .. I think. I seem to be able
to read back written blocks and nothing is ever accounted through
the rest of the driver code.  Shouldn't I endio the bh and then drop it
from the request? 

In the case when the getblk returned something that wasn't in the
cache (i.e. different from the original bh), I am running endio on
it immediately, as I believe it must be a zero filled block. 

This all works, I think. I'll keep checking though. 

Peter