public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <Martin@lichtvoll.de>
To: linux-xfs@oss.sgi.com
Cc: David Chinner <dgc@sgi.com>
Subject: Re: XFS and write barriers.
Date: Thu, 29 Mar 2007 18:49:38 +0200	[thread overview]
Message-ID: <200703291849.44297.Martin@lichtvoll.de> (raw)
In-Reply-To: <20070329151858.GI32597093@melbourne.sgi.com>

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

Am Donnerstag 29 März 2007 schrieb David Chinner:
> On Thu, Mar 29, 2007 at 04:56:21PM +0200, Martin Steigerwald wrote:
> > Am Montag 26 März 2007 schrieb David Chinner:
> > > > Is there some mount flag to say "cope without barriers" or
> > > > "require barriers" ??
> > >
> > > XFs has "-o nobarrier" to say don't use barriers, and this is
> > > *not* the default. If barriers don't work, we drop back to "-o
> > > nobarrier" after leaving a loud warning inthe log....
> >
> > Hello David!
> >
> > Just a thought, maybe it shouldn't do that automatically, but require
> > the sysadmin to explicitely state "-o nobarrier" in that case.
>
> And prevent most existing XFS filesystems from mounting after
> a kernel upgrade? Think about the problems that might cause
> with XFs root filesystems on hardware/software that doesn't
> support barriers....

Hello David!

Granted. So it might turn out to be a decision between does not boot or is 
not totally safe in power outages or crashes. I see no easy default 
answer to that.

So while probably being a layering violation at least trying to disable 
the write cache on devices without cache flush support unless "-o 
nobarrier" (as in "I know what I am doing") is given, might help safety. 
But this adds complexity and a possible source for bugs. And maybe trying 
to disable write cache isn't safe on all setups?

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-03-29 16:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-23  1:26 XFS and write barriers Neil Brown
2007-03-23  5:30 ` David Chinner
2007-03-23  7:49   ` Neil Brown
2007-03-25  4:17     ` David Chinner
2007-03-25 23:21       ` Neil Brown
2007-03-26  3:14         ` David Chinner
2007-03-26  4:27           ` Neil Brown
2007-03-26  9:04             ` David Chinner
2007-03-29 14:56               ` Martin Steigerwald
2007-03-29 15:18                 ` David Chinner
2007-03-29 16:49                   ` Martin Steigerwald [this message]
2007-03-23  9:50   ` Christoph Hellwig
2007-03-25  3:51     ` David Chinner
2007-03-25 23:58       ` Neil Brown
2007-03-26  1:11     ` Neil Brown
2007-03-23  6:20 ` Timothy Shimmin
2007-03-23  8:00   ` Neil Brown
2007-03-25  3:19     ` David Chinner
2007-03-26  0:01       ` Neil Brown
2007-03-26  3:58         ` David Chinner
2007-03-27  3:58       ` Timothy Shimmin

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=200703291849.44297.Martin@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=dgc@sgi.com \
    --cc=linux-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