public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
	Jens Axboe <axboe@suse.de>, Jeff Garzik <jgarzik@pobox.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] barrier patch set
Date: Tue, 30 Mar 2004 14:19:45 -0500	[thread overview]
Message-ID: <1080674384.3548.36.camel@watt.suse.com> (raw)
In-Reply-To: <1080662685.1978.25.camel@sisko.scot.redhat.com>

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



  reply	other threads:[~2004-03-30 19:19 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-19 15:35 [PATCH] barrier patch set Jens Axboe
2004-03-19 16:30 ` Mika Penttilä
2004-03-19 18:16   ` Jens Axboe
2004-03-19 18:44     ` Mika Penttilä
2004-03-20  9:55       ` Jens Axboe
2004-03-19 16:34 ` Jeff Garzik
2004-03-19 18:19   ` Jens Axboe
2004-03-19 23:01   ` Matthias Andree
2004-03-20  0:02     ` Bartlomiej Zolnierkiewicz
2004-03-20  1:48       ` Johannes Stezenbach
2004-03-20  2:13         ` Bartlomiej Zolnierkiewicz
2004-03-20  2:53           ` Johannes Stezenbach
2004-03-20 16:03             ` Bartlomiej Zolnierkiewicz
2004-03-20 11:36           ` Matthias Andree
2004-03-20 16:00             ` Bartlomiej Zolnierkiewicz
2004-03-20 23:36               ` Johannes Stezenbach
2004-03-21  1:33                 ` Bartlomiej Zolnierkiewicz
2004-03-20 18:52       ` Helge Hafting
2004-03-22 11:15         ` Matthias Andree
2004-03-19 23:59   ` Bartlomiej Zolnierkiewicz
2004-03-20  0:14     ` Jeff Garzik
2004-03-20  0:40       ` Bartlomiej Zolnierkiewicz
2004-03-20  0:42         ` Jeff Garzik
2004-03-20  1:24           ` Bartlomiej Zolnierkiewicz
2004-03-20  9:58             ` Jens Axboe
2004-03-20 10:12               ` Jeff Garzik
2004-03-20 10:19                 ` Jens Axboe
2004-03-20 10:37                   ` Jeff Garzik
2004-03-20 16:30                     ` Bartlomiej Zolnierkiewicz
2004-03-21 18:12                       ` Jeff Garzik
2004-03-20 10:21             ` Jeff Garzik
2004-03-20 15:54               ` Bartlomiej Zolnierkiewicz
2004-03-20  0:17     ` Jeff Garzik
2004-03-20  9:53     ` Jens Axboe
2004-03-20 16:23       ` Bartlomiej Zolnierkiewicz
2004-03-20 16:27         ` Jens Axboe
2004-03-20 16:32         ` Chris Mason
2004-03-20 17:05           ` Bartlomiej Zolnierkiewicz
2004-03-20 17:10             ` Chris Mason
2004-03-20 20:16               ` Bartlomiej Zolnierkiewicz
2004-03-21  9:43                 ` Jens Axboe
2004-03-30 16:04             ` Stephen C. Tweedie
2004-03-30 19:19               ` Chris Mason [this message]
2004-03-30 21:50                 ` Stephen C. Tweedie
2004-03-30 22:13                   ` Chris Mason
2004-03-31 14:03                     ` Stephen C. Tweedie
2004-03-31 14:27                       ` Chris Mason
2004-03-31 18:28                         ` Ric Wheeler
2004-03-30 22:21                   ` Jeff Garzik
2004-03-30 22:36                     ` Chris Wedgwood
2004-03-30 22:39                       ` Jeff Garzik
2004-03-30 22:41                         ` Chris Wedgwood
2004-03-30 22:40                     ` Bartlomiej Zolnierkiewicz
2004-03-30 22:38                       ` Jeff Garzik
2004-03-31 14:08                     ` Stephen C. Tweedie
2004-03-31 14:21                       ` Chris Mason
2004-03-31 21:26                         ` Jeff Garzik
2004-03-31 22:09                           ` Chris Mason
2004-03-31 21:27                       ` Jeff Garzik
2004-03-19 16:48 ` Marc-Christian Petersen
2004-03-19 18:19   ` Jens Axboe
2004-03-22 11:09 ` Andrew Morton
2004-03-22 11:10   ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1080674384.3548.36.camel@watt.suse.com \
    --to=mason@suse.com \
    --cc=B.Zolnierkiewicz@elka.pw.edu.pl \
    --cc=axboe@suse.de \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sct@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox