From: Ralf Liebenow <ralf@theco.de>
To: xfs@oss.sgi.com
Subject: Re: xfs_force_shutdown after Raid crash
Date: Wed, 4 Feb 2009 16:33:22 +0100 [thread overview]
Message-ID: <20090204153322.GC15454@theco.de> (raw)
In-Reply-To: <20090204122241.GL24173@disturbed>
Hello !
Maybe this is a stupid question:
Should Battery backed RAID controllers not always set their discs cache off ?
As I see it (in case of a power failure):
- the discs are connectet to the main power, so if there is a power
failure they're offline at that moment in time and their (write) cache will
be gone in that instance of time too
- if they are connected to a battery backed RAID cache, I assume that
this cache will be written as soon as the system is online again
(if the battery lasts that long)
- if a RAID controller does not turn off the disks write cache, the controller
cannot know if previous writes have made it to the disk. A good
RAID Controller would also use its cache to re-organise the disc
writes to minimize seek times doing somthing like intelligent
command queuing. This would also mean, that any order of writes
to a disk could have been changed by the controller. This would
ultimately break any filesystem which does not explicitly fsyncing
consistent checkpoints to the disk, which would make battery backed
RAID Systems pretty useless ... would it ?
So .. a battery backed RAID controller should default to "no disk write cache"
should it ? Otherwise why should anyone want to use such expensive
controllers ... it just does not make sense to have a battery backed
cache on the controller, when things get inconsistent at a power
outage ... It wouldn't have any purpuse ... I hope developers of
battery backed RAID controllers are aware of that implication ...
Greets
Ralf
> On Wed, Feb 04, 2009 at 09:52:45AM +0100, Michael Monnerie wrote:
> > On Dienstag 03 Februar 2009 Christoph Hellwig wrote:
> > > Yeah, that sounds correct. Do you volunteer for the FAQ entry?
> > > xfs.org is a wiki so you could add it. I'm happy to proof-read it
> > > if you want.
> >
> > I don't know if it's good and correct, I just put this in the wiki, and
> > additionally changed 2 sections, please check the wiki log if it's
> > correct:
> >
> > == Q. What about the hard disk write cache? ==
> >
> > The problem with hard disk write caches is that their contents are lost
> > in case of a power outage. With hard disk cache sizes of currently up to
> > 32MB that can be a lot of valuable information.
> >
> > With a single hard disk and barriers turned on (on=default), a powerfail
> > "only" looses data in the cache but at least does not destroy the
> > filesystem.
>
> I'd drop this paragraph - powerfail can destroy filesystems even on
> a single disk (e.g. root directory gets corrupted).
>
> > With a RAID controller with battery backed cache, you should turn off
> > barriers, as recommended above. But then you *must* disable the hard
> > disk write cache in order to ensure to keep the filesystem intact after
> > a power failure.
>
> I'd change this to say "*must* disable the individual hard disk
> write caches" to make it clear that it is referencing the disks
> behind the raid controller. I'd also say "The method for doing this
> is different for each RAID controller. Please consult your RAID
> controller documentation to determine how to change these settings."
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
--
theCode AG
HRB 78053, Amtsgericht Charlottenbg
USt-IdNr.: DE204114808
Vorstand: Ralf Liebenow, Michael Oesterreich, Peter Witzel
Aufsichtsratsvorsitzender: Wolf von Jaduczynski
Oranienstr. 10-11, 10997 Berlin [×]
fon +49 30 617 897-0 fax -10
ralf@theCo.de http://www.theCo.de
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-02-04 15:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-30 21:53 xfs_force_shutdown after Raid crash Steffen Knauf
2009-01-31 10:57 ` Christoph Hellwig
2009-02-03 1:22 ` Michael Monnerie
2009-02-03 3:13 ` Eric Sandeen
2009-02-03 9:22 ` Michael Monnerie
2009-02-03 9:32 ` Christoph Hellwig
2009-02-03 10:40 ` Michael Monnerie
2009-02-03 15:49 ` Christoph Hellwig
2009-02-04 8:52 ` Michael Monnerie
2009-02-04 10:27 ` Michael Monnerie
2009-02-04 12:26 ` Dave Chinner
2009-02-04 15:03 ` Michael Monnerie
2009-02-13 10:12 ` Michael Monnerie
2009-02-04 12:22 ` Dave Chinner
2009-02-04 12:45 ` Emmanuel Florac
2009-02-04 14:01 ` KELEMEN Peter
2009-02-04 15:15 ` Emmanuel Florac
2009-02-04 15:25 ` Michael Monnerie
2009-02-04 15:41 ` KELEMEN Peter
2009-02-04 16:01 ` Michael Monnerie
2009-02-04 16:23 ` Emmanuel Florac
2009-02-04 15:24 ` Michael Monnerie
2009-02-05 8:37 ` Dave Chinner
2009-02-04 15:33 ` Ralf Liebenow [this message]
2009-02-04 16:18 ` Michael Monnerie
2009-02-05 8:22 ` Michael Monnerie
2009-02-05 12:05 ` Emmanuel Florac
2009-02-06 15:57 ` Steffen Knauf
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=20090204153322.GC15454@theco.de \
--to=ralf@theco.de \
--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