From: Jens Axboe <axboe@suse.de>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: David Balazic <david.balazic@uni-mb.si>,
torvalds@transmeta.com,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: scsi vs ide performance on fsync's
Date: Wed, 7 Mar 2001 19:51:52 +0100 [thread overview]
Message-ID: <20010307195152.C4653@suse.de> (raw)
In-Reply-To: <3AA53DC0.C6E2F308@uni-mb.si> <20010306213720.U2803@suse.de> <20010307135135.B3715@redhat.com> <20010307151241.E526@suse.de> <20010307150556.L7453@redhat.com>
In-Reply-To: <20010307150556.L7453@redhat.com>; from sct@redhat.com on Wed, Mar 07, 2001 at 03:05:56PM +0000
On Wed, Mar 07 2001, Stephen C. Tweedie wrote:
> > Yep, it's much harder than it seems. Especially because for the barrier
> > to be really useful, having inter-request dependencies becomes a
> > requirement. So you can say something like 'flush X and Y, but don't
> > flush Y before X is done'.
>
> Yes. Fortunately, the simplest possible barrier is just a matter of
> marking a request as non-reorderable, and then making sure that you
> both flush the elevator queue before servicing that request, and defer
> any subsequent requests until the barrier request has been satisfied.
> One it has gone through, you can let through the deferred requests (in
> order, up to the point at which you encounter another barrier).
The above should have been inter-queue dependencies. For one queue
it's not a big issue, you basically described the whole sequence
above. Either sequence it as zero for a non-empty queue and make
sure the low level driver orders or flushes, or just hand it directly
to the device.
My bigger concern is when the journalled fs has a log on a different
queue.
> Only if the queue is empty can you give a barrier request directly to
> the driver. The special optimisation you can do in this case with
> SCSI is to continue to allow new requests through even before the
> barrier has completed if the disk supports ordered queue tags.
Yep, IDE will have to pay the price of a flush.
--
Jens Axboe
next prev parent reply other threads:[~2001-03-07 18:52 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-06 19:42 scsi vs ide performance on fsync's David Balazic
2001-03-06 20:37 ` Jens Axboe
2001-03-07 13:51 ` Stephen C. Tweedie
2001-03-07 14:12 ` Jens Axboe
2001-03-07 15:05 ` Stephen C. Tweedie
2001-03-07 18:51 ` Jens Axboe [this message]
2001-03-07 19:10 ` Stephen C. Tweedie
2001-03-07 20:15 ` Jens Axboe
2001-03-07 20:56 ` Stephen C. Tweedie
2001-03-07 20:59 ` Jens Axboe
2001-03-08 15:45 ` Chris Mason
[not found] <1epyyz1.etswlv1kmicnqM%smurf@noris.de>
2001-03-09 6:59 ` Matthias Urlichs
2001-03-09 11:51 ` Jens Axboe
2001-03-09 14:26 ` Matthias Urlichs
-- strict thread matches above, loose matches on Subject: below --
2001-03-07 12:47 David Balazic
2001-03-06 17:14 David Balazic
2001-03-06 17:46 ` Gregory Maxwell
2001-03-06 18:23 ` Jonathan Morton
2001-03-06 23:27 ` Mark Hahn
2001-03-06 5:27 Douglas Gilbert
2001-03-06 5:45 ` Linus Torvalds
2001-03-06 7:12 ` Andre Hedrick
2001-03-06 12:09 ` Alan Cox
2001-03-06 18:44 ` Linus Torvalds
2001-03-07 13:48 ` Stephen C. Tweedie
2001-03-07 14:13 ` Jens Axboe
2001-03-12 18:50 ` Andre Hedrick
2001-03-06 13:50 ` Mike Black
2001-03-06 16:02 ` Jeremy Hansen
2001-03-07 18:27 ` Jeremy Hansen
2001-03-07 18:36 ` Linus Torvalds
2001-03-08 11:06 ` Stephen C. Tweedie
2001-03-06 16:57 ` Jonathan Morton
2001-03-06 6:43 ` Jonathan Morton
2001-03-06 13:03 ` dean gaudet
2001-03-06 13:15 ` dean gaudet
2001-03-06 13:45 ` Jonathan Morton
[not found] <Pine.LNX.4.33L2.0103021033190.6176-200000@srv2.ecropolis.com>
[not found] ` <054201c0a33d$55ee5870$e1de11cc@csihq.com>
2001-03-04 20:10 ` Douglas Gilbert
2001-03-04 21:28 ` Ishikawa
2001-03-06 0:11 ` Douglas Gilbert
2001-03-02 17:42 Jeremy Hansen
2001-03-02 18:39 ` Steve Lord
2001-03-02 19:17 ` Chris Mason
2001-03-02 19:25 ` Steve Lord
2001-03-02 19:27 ` Jeremy Hansen
2001-03-02 19:38 ` Chris Mason
2001-03-02 19:41 ` Steve Lord
2001-03-05 13:23 ` Andi Kleen
2001-03-02 19:25 ` Andre Hedrick
2001-03-03 1:55 ` Dan Hollis
2001-03-02 20:56 ` Linus Torvalds
2001-03-06 2:13 ` Jeremy Hansen
2001-03-06 2:25 ` Linus Torvalds
2001-03-06 3:30 ` Jonathan Morton
2001-03-06 4:05 ` Linus Torvalds
2001-03-06 7:03 ` Andre Hedrick
2001-03-06 8:24 ` Jonathan Morton
2001-03-06 12:22 ` Rik van Riel
2001-03-06 14:08 ` Jonathan Morton
2001-03-07 16:50 ` Pavel Machek
2001-03-06 19:41 ` Andre Hedrick
2001-03-07 5:25 ` Jonathan Morton
2001-03-07 6:58 ` Andre Hedrick
2001-03-09 11:39 ` Jonathan Morton
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=20010307195152.C4653@suse.de \
--to=axboe@suse.de \
--cc=david.balazic@uni-mb.si \
--cc=linux-kernel@vger.kernel.org \
--cc=sct@redhat.com \
--cc=torvalds@transmeta.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;
as well as URLs for NNTP newsgroup(s).