Re: [PATCH] barrier patch set

[Chris Mason]

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

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"

(roughly)

-chris


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