xfs_force_shutdown after Raid crash

[Michael Monnerie]

On Mittwoch 04 Februar 2009 Michael Monnerie wrote:
> >   - 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.

I have an answer from Areca support:
*******************************************************
as soon as the hard drive firmware response command completed, the data 
will be remove from controller cache. so controller will not known the 
data had been trully write into disks or remain in hard drive cache 
only.

by controller default setting, if controller have battery module 
connected, it will automatically disable the hard drive cache for best 
data protection. as you known, controller can't protect the data remain 
in hard drive cache while power outage occured.

but this setting is configure-able, some customer may forece enable the 
hard drive cacne for better performance. beucase hard drive without 
cache enabled have quite poor performance.
*******************************************************
So I'd say they have a very sensible default: 
If you use a BBM (battery backup module) then disk write caches will be 
off, because you care about your data. 
If you dont use a BBM anyway, they let disk write cache on because your 
data is not save at all, so why care? 8-) And as most magazines will 
test without a BBM, it improves speed up to the max, which is good for 
benchmarks :-)

I'll put a section with RAID controllers into the wiki, if someone has 
objections we can remove it again.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20090205/9a2194cc/attachment.sig>