[ENBD] proxing ioctl's

[Peter T. Breuer]

"A month of sundays ago Daniel Shane wrote:"
> Its rd.c in drivers/block, in the do_rd_request() function. 

The relevant lines seem to me to be these:

  mark_buffer_protected(rbh);
  brelse(rbh);

but I've just noticed that they don't run endio over the target
bh (rbh) but over the source bh (sbh).

Now they have left me somewhat confused. I THOUGHT that they were
simply marking the buffer protected and then running the generic
endio over it. But now I see that they instead seem to be
running endio over the orignal after having made a copy. Ahhhhh ...
shucks.

 rbh = getblk(sbh->b_rdev, sbh->b_rsector/(sbh->b_size>>9), sbh->b_size);
 /* I think that it is safe to assume that rbh is not in
  * HighMem, though sbh might be - NeilBrown
  */

makes the copy. Then they do

   bdata = bh_kmap(sbh);

this must get the buffer area of the source. Why all that palaver?
Isn't it just sbh->b_data? Then they copy into the bdata buffer
from the rbh buffer on read, or copy it into the new buffer (rbh)
on write. All provided the two are different, of course, which measn
the area was not cached.

Then they 

   bh_kunmap(sbh)

huh? Then they do the trick I noted at the beginning on rbh, and they
DON'T run endio on it, but instead on the old buffer.

    sbh->b_end_io(sbh,1);
    return 0;

So it looks as though on write they get a new buffer if necessary and
save into that. What I don't quite get is why on read they test to
see if the request was buffered .. I expect requests satisfied by the
VFS layers not to fall through to us at all. Can they now arrive at the
drivers also?

That would explain certain observations ..  namely that in some sense
VFS layer caching seems to have disappeared for nbd in 2.4.0 (this is
very useful, as it means that multi-machine write requests are now
automatically "working" against a single server).

But I am also puzzled because the rd.c code runs end_io on the sbh (the
source buffer) whether or not it is the same as the target buffer_head.
(rbh). 

What about on read? Is it now up to us in the driver code to go through
each request and se if it can be satisfied locally, with a getblk()?
It would seem so.

Where has the VFS layer gone to?




Peter