Re: block: eliminate ELEVATOR_INSERT_REQUEUE

[Tejun Heo]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/