lkml.org 
[lkml]   [2004]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: flush cache range proposal (was Re: ide errors in 7-rc1-mm1 and later)
    On Fri, Jun 11 at  9:55, Jens Axboe wrote:
    >Proposal looks fine, but please lets not forget that flush cache range
    >is really a band-aid because we don't have a proper ordered write in the
    >first place. Personally, I'd much rather see that implemented than flush
    >cache range. It would be way more effective.

    So something like:

    WRITE FIRST PARTY DMA QUEUED BARRIER EXT
    READ FIRST PARTY DMA QUEUED BARRIER EXT
    READ DMA QUEUED BARRIER EXT
    READ DMA QUEUED BARRIER
    WRITE DMA QUEUED BARRIER
    WRITE DMA QUEUED BARRIER EXT


    ...

    If the drive receives a queued barrier write (NCQ or Legacy), it will
    finish processing all previously-received queued commands and post
    good status for them, then it will process the barrier operation, post
    status for that barrier operation, then it will continue processing
    queued commands in the order received.

    Multiple barrier operations can be in the queue at the same time. A
    barrier operation has an implied FUA associated with it, such that the
    command (and all previous-in-time commands) must be pushed to the
    media before command completetion can be indicated.


    Is that what would be most useful?

    --eric



    --
    Eric D. Mudama
    edmudama@mail.bounceswoosh.org

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

    \
     
     \ /
      Last update: 2005-03-22 14:03    [W:5.112 / U:0.568 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site