Messages in this thread |  | | Date | Sun, 11 Nov 2001 11:38:47 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [CFT][PATCH] long-living cache for block devices |
| |
On Sun, 11 Nov 2001, Alexander Viro wrote: > > > > 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.
read and write requests are on the same queue. Starting write requests starts the read requests.
And we will _not_ be adding any more read requests if the device count has gone down to zero.
> Sure. But there may very well be requests coming into driver from the > queue.
So? We should wait for the QUEUE, not for something 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...
No, I want the _shutdown_ to wait for all requests. It could even be as simple as
generic_unplug_queue(q); while (!queue_empty(q)) { set_task_state(TASK_UNINTERRUPTIBLE); schedule_timeout(1); }
but if we want to be fancy we allow shared queues to ignore other drivers that share the queue (queue sharing is really not supposed to happen any more, though, and neither IDE nor SCSI do it, so I doubt it matters).
So the above would be called from "invalidate_bdev()" or something..
Hmm.. Looking at "invalidate_bdev()", I doubt it matters, actually - it will already wait for all buffers, whether dirty or not. So it looks like it would already be impossible to have buffers on the queue.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |