All of lore.kernel.org
 help / color / mirror / Atom feed
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 21:15:36 +0100	[thread overview]
Message-ID: <20010307211536.G4653@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> <20010307195152.C4653@suse.de> <20010307191044.M7453@redhat.com>
In-Reply-To: <20010307191044.M7453@redhat.com>; from sct@redhat.com on Wed, Mar 07, 2001 at 07:10:44PM +0000

On Wed, Mar 07 2001, Stephen C. Tweedie wrote:
> On Wed, Mar 07, 2001 at 07:51:52PM +0100, Jens Axboe wrote:
> > On Wed, Mar 07 2001, Stephen C. Tweedie wrote:
> > 
> > My bigger concern is when the journalled fs has a log on a different
> > queue.
> 
> For most fs'es, that's not an issue.  The fs won't start writeback on
> the primary disk at all until the journal commit has been acknowledged
> as firm on disk.

But do you then force wait on that journal commit?

> Certainly for ext3, synchronisation between the log and the primary
> disk is no big thing.  What really hurts is writing to the log, where
> we have to wait for the log writes to complete before submitting the
> commit write (which is sequentially allocated just after the rest of
> the log blocks).  Specifying a barrier on the commit block would allow
> us to keep the log device streaming, and the fs can deal with
> synchronising the primary disk quite happily by itself.

A barrier operation is sufficient then. So you're saying don't
over design, a simple barrier is all you need?

-- 
Jens Axboe


  reply	other threads:[~2001-03-07 20:16 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
2001-03-07 19:10           ` Stephen C. Tweedie
2001-03-07 20:15             ` Jens Axboe [this message]
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=20010307211536.G4653@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.