From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: ralf@theco.de, xfs@oss.sgi.com
Subject: Re: xfs_force_shutdown after Raid crash
Date: Wed, 4 Feb 2009 17:18:15 +0100 [thread overview]
Message-ID: <200902041718.15836@zmi.at> (raw)
In-Reply-To: <20090204153322.GC15454@theco.de>
[-- Attachment #1.1: Type: text/plain, Size: 2739 bytes --]
On Mittwoch 04 Februar 2009 Ralf Liebenow wrote:
> 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
Normally a server is on a UPS, and that should report when there's a
power outage so the server has enough time to gracefully shut down.
Still, there can be other events such as:
- power supply error. Even with redundant PS, an outage can exist
- human error (coffee into the server, someone unplugging the cable
between UPS and server,...)
- and of course mainboard/cpu/ram total crashes
so you are basically never safe.
> - 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.
The controller could keep in-transfer blocks in it's cache, waiting for
a confirm from the disk that the blocks are on the media, and only
afterwards remove it from cache. I don't know if controllers do that
actually. I'll ask Areca support on that.
> 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 ...
Yes, imagine you have a RAID with 8 hard disks each having 32MB cache...
up to 256MB data lost, with a very big chance of having filesystem
metadata in cache, as that's written very often...
I'll be back on that once I have an official answer from Areca.
mfg zmi
--
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0660 / 415 65 31 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-02-04 16:18 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
2009-02-04 16:18 ` Michael Monnerie [this message]
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=200902041718.15836@zmi.at \
--to=michael.monnerie@is.it-management.at \
--cc=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 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.