From: Eric Sandeen <sandeen@sandeen.net>
To: Timothy Shimmin <tes@sgi.com>
Cc: xfs-oss <xfs@oss.sgi.com>, LinuxRaid <linux-raid@vger.kernel.org>,
NeilBrown <neilb@suse.de>,
jeremy@sgi.comwe
Subject: Re: [PATCH] disable queue flag test in barrier check
Date: Thu, 26 Jun 2008 08:25:11 -0500 [thread overview]
Message-ID: <486398B7.50306@sandeen.net> (raw)
In-Reply-To: <48635284.3060001@sgi.com>
Timothy Shimmin wrote:
> Also from memory, I believe Neil checked this removal into the SLES10sp1 tree
> and some sgi boxes started having slow downs
> (looking at Dave's email below - we were not wanting to tell them
> to use nobarrier but needed it to work by default - I forget now).
But that's an admin issue.
The way it is now, for example a home user of md raid1 (me!) can't run
barriers even if they wanted to.
Until there is a way to know if a write cache is non-volatile the only
safe option is to enable barriers when possible.
> 6.
>> Date: Wed, 25 Jun 2008 08:57:24 +1000
>> From: Dave Chinner <david@fromorbit.com>
>> To: Eric Sandeen <sandeen@sandeen.net>
>> Cc: LinuxRaid <linux-raid@vger.kernel.org>, xfs-oss <xfs@oss.sgi.com>
>> Subject: Re: md raid1 passes barriers, but xfs doesn't use them?
>>
>> 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. 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....
>>
>> Cheers,
>>
>> Dave.
>
> So I guess my question is whether there are cases where we are
> going to be in trouble again.
> Jeremy, do you see some problems?
FWIW, the problem *I* foresee is that some people are going to slow down
when using the defaults, yes, because barriers will start working again.
But I don't see any other safe way around it.
Education would be in order, I suppose. :)
-Eric
> --Tim
>
>
>
next prev parent reply other threads:[~2008-06-26 13:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-26 3:07 [PATCH] disable queue flag test in barrier check Eric Sandeen
2008-06-26 8:25 ` Timothy Shimmin
2008-06-26 13:25 ` Eric Sandeen [this message]
2008-06-26 14:47 ` David Lethe
2008-06-26 14:47 ` David Lethe
2008-06-26 14:57 ` Eric Sandeen
2008-06-27 4:51 ` Timothy Shimmin
-- strict thread matches above, loose matches on Subject: below --
2008-06-26 15:24 David Lethe
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=486398B7.50306@sandeen.net \
--to=sandeen@sandeen.net \
--cc=jeremy@sgi.comwe \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=tes@sgi.com \
--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 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.