Messages in this thread | | | Date | Wed, 30 Mar 2011 16:27:51 +0200 | From | Tejun Heo <> | Subject | Re: block: eliminate ELEVATOR_INSERT_REQUEUE |
| |
On Wed, Mar 30, 2011 at 10:01:24AM -0400, Mike Snitzer wrote: > Why can we all of a sudden append the flush to the dispatch queue _but_ > not have any concern about queue draining? Seems that avoiding use of > BACK, by using list_add_tail, is enabling that. Couldn't we have always > done that?
Yes, we could have. I was just being lazy and looking for an easy solution.
> The folding of elv_insert() into __elv_add_request() seems > irrelevant.
Strictly, it is but they kinda go well together.
> Can we take a step back and be more explicit about the implications of > having inserted the flush with REQUEUE/FRONT? Seems to me that having > _not_ inserted the flush at the end of the dispatch queue is cause for > potential corruption (preceding data hasn't been issued to the device > yet).
No, the data ordering is enforced by the filesystem in the new implementation meaning that by the time FLUSH is issued by the filesystem, it should have made sure that all requests which must be written before the FLUSH already had completed.
> And just to be clear: none of this is a concern for stable right? It is > just the flush-merge code introduced for 2.6.39 that needs fixing?
I think 2.6.38 needs a -stable fix. It has the previous version of the new flush implementation and is using front insertion.
Thanks.
-- tejun
| |