[lkml]   [2011]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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

    > 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.



     \ /
      Last update: 2011-03-30 16:31    [W:0.021 / U:5.168 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site