Re: [CFT][PATCH] long-living cache for block devices

[Alexander Viro]

On Sun, 11 Nov 2001, Linus Torvalds wrote:

> 
> On Sun, 11 Nov 2001, Alexander Viro wrote:
> >
> > As it is, driver has a right to destroy any internal data structures as
> > soon as the last ->release() is called.  None of them expect requests
> > coming in after that and frankly, that makes sense.
> 
> New requests will not be coming in - not for read-ahead, not for anything
> else.
> 
> There may be old requests that haven't finished, of course. And there may
> be requests on the request queue that the driver hasn't even looked at yet
> (Hmm.. I'm not sure that latter one is right - we must have done the
> device sync anyway, and that will unplug the requests queue etc).

Why would it?  Sync deals with write requests, read requests are left as-is.
Notice that in your tree the thing shuts readahead requests down is
invalidate_bdev() and we don't want to get it called - for very obvious
reasons.
 
> But there cannot be any users that are still adding requests. That would
> be a bug regardless.

Sure.  But there may very well be requests coming into driver from the
queue.

> We might want to make sure that the request queue is truly empty, that's
> for sure. That's a driver-level thing that makes sense, and that should
> probably be part of the logic that does the bdev sync. After all, that
> queue should be a per-driver thing anyway (right now it isn't, but hey,
> that's for all the wrong historical reasons rather than anything else).

Umm... So you want sync to wait for read requests, not just the write ones?
That would certainly be enough, but that's not what everyone expects from
sync...