linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Eric Sandeen <sandeen@sandeen.net>,
	LinuxRaid <linux-raid@vger.kernel.org>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: md raid1 passes barriers, but xfs doesn't use them?
Date: Tue, 24 Jun 2008 20:49:59 -0500	[thread overview]
Message-ID: <4861A447.5090208@sandeen.net> (raw)
In-Reply-To: <20080624225724.GN29319@disturbed>

Dave Chinner wrote:
> On Mon, Jun 23, 2008 at 09:23:10PM -0500, Eric Sandeen wrote:


>> Maybe there should be a QUEUE_ORDERED_PASSTHRU flag?
>> Or should XFS just stick with the test write and ignore the flag?  I'm
>> not sure of the queue->ordered flag details, but it seems that XFS & md
>> raid1 both try hard to keep barriers in force, and there's a disconnect
>> here somewhere.
> 
> Yeah, the problem was that last time this check was removed was
> that a bunch of existing hardware had barriers enabled on them when
> not necessary (e.g. had NVRAM) and they went 5x slower on MD raid1
> devices. 

Hm,
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c#rev1.402,
 putting back what was removed in
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c#rev1.380
 I guess.  But this seems like a very weird argument to me.  Whether a
drive/raid has battery backed raid, is 1 spindle or 100, is connected to
a UPS or whatnot really is orthogonal to what should be set on the queue
flag... This should be an admin decision.  Leaving it this way for this
odd reason leaves smaller users w/ 2 raid1 spindles in the desktop box
actually completely unable to use barriers even if they wanted to;
removing the check at least lets the savvy admin mount with an option to
turn them off.

> Having to change the root drive config on a wide install
> base was considered much more of support pain than leaving the
> check there. I guess that was more of a distro upgrade issue than
> a mainline problem, but that's the history. Hence I think we
> should probably do whatever everyone else is doing here...

I'll submit a patch to remove the check ;)

-Eric

> 
> Cheers,
> 
> Dave.


      reply	other threads:[~2008-06-25  1:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-24  2:23 md raid1 passes barriers, but xfs doesn't use them? Eric Sandeen
2008-06-24 22:57 ` Dave Chinner
2008-06-25  1:49   ` Eric Sandeen [this message]

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=4861A447.5090208@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=linux-raid@vger.kernel.org \
    --cc=xfs@oss.sgi.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).