All of lore.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 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.