[lkml]   [2004]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] barrier patch set
    On Tue, 2004-03-30 at 11:04, Stephen C. Tweedie wrote:

    [ barriers vs ordered writes ]

    > The distinction becomes important if flushing and barriers have
    > significantly different performance characteristics. In the SCSI tagged
    > command case, we can insert an ORDERED queue tag into the pipeline
    > without having to wait for anything. But if we implement the barrier
    > and the flush by the same mechanism, then the fs ends up waiting; we get
    > write log blocks
    > wait for IO queue to empty
    > write commit block
    > wait for IO queue to empty
    > instead of
    > write log blocks
    > write commit block with ORDERED tag set
    > so the commits are miles slower.
    I think we're mixing a few concepts together. submit_bh(WRITE_BARRIER,
    bh) gives us an ordered write in whatever form the lower layers can
    provide. It also ensures that if you happen to call wait_on_buffer()
    for the barrier buffer, the wait won't return until the data is on

    The construct allows for the second type of commit you describe above,
    where wait_on_buffer is not called on the log blocks until after the
    commit block has been sent down the pipe. The reiserfs barrier patch
    does this now.

    The fact that IDE implements the barriers via a flush and that no other
    layer has barriers right now is secondary ;) I do want to revive some
    kind of ordering for scsi as well, but since IDE is a safety issue right
    now I wanted to concentrate there first.

    > Jens' patch happens to implement barriers via flushes on IDE, but at the
    > block layer blkdev_issue_flush() and set_buffer_ordered() are quite
    > distinct APIs.

    Yes, they are completely different. blkdev_issue_flush is the kernel
    recognizing that wait_on_buffer (or page or whatever) isn't always
    enough to make sure writes are really done. It has no ordering
    semantics at all, it just means "really write what you've already told
    me is written, unless you promise via battery backed cache that it will
    get to disk eventually"



    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:02    [W:0.023 / U:384.284 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site