linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Iustin Pop <iusty@k1024.org>
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Cc: Jordan Russell <jr-list-2007@quo.to>, linux-raid@vger.kernel.org
Subject: Re: MD RAID1 performance very different from non-RAID partition
Date: Sat, 15 Sep 2007 14:32:17 +0200	[thread overview]
Message-ID: <20070915123217.GC21515@teal.hq.k1024.org> (raw)
In-Reply-To: <87ejh03ywk.fsf@informatik.uni-tuebingen.de>

On Sat, Sep 15, 2007 at 02:18:19PM +0200, Goswin von Brederlow wrote:
> Shouldn't it be the other way around? With a barrier the filesystem
> can enforce an order on the data written and can then continue writing
> data to the cache. More data is queued up for write. Without barriers
> the filesystem should do a sync at that point and have to wait for the
> write to fully finish. So less is put into cache.

I don't know in general, but XFS will simply not issue any sync at all
if the block device doesn't support barriers. It's the syadmin's job to
either ensure you have barriers or turn off write cache on disk (see the
XFS faq, for example).

However, I never saw such behaviour from MD (i.e. claiming the write has
completed while the disk underneath is still receiving data to write
from Linux) so I'm not sure this is what happens here. In my experience,
MD acknowledges a write only when it has been pushed to the drive (write
cache enabled or not) and there is no buffer between MD and the drive.

regards,
iustin

  reply	other threads:[~2007-09-15 12:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-15  5:28 MD RAID1 performance very different from non-RAID partition Jordan Russell
2007-09-15  7:09 ` Iustin Pop
2007-09-15 12:18   ` Goswin von Brederlow
2007-09-15 12:32     ` Iustin Pop [this message]
2007-09-15 18:11   ` Jordan Russell
2007-09-16 22:08     ` Goswin von Brederlow
2007-09-17 15:58       ` Jordan Russell
2007-09-18 13:44         ` Luca Berra
2007-09-19  5:28           ` Jordan Russell

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=20070915123217.GC21515@teal.hq.k1024.org \
    --to=iusty@k1024.org \
    --cc=brederlo@informatik.uni-tuebingen.de \
    --cc=jr-list-2007@quo.to \
    --cc=linux-raid@vger.kernel.org \
    /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).