xfs
[Top] [All Lists]

Re: xfs_force_shutdown after Raid crash

To: xfs@xxxxxxxxxxx
Subject: Re: xfs_force_shutdown after Raid crash
From: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 3 Feb 2009 10:22:38 +0100
In-reply-to: <4987B673.8030406@xxxxxxxxxxx>
Organization: it-management http://it-management.at
References: <498376CF.8020806@xxxxxxxxxxxxxx> <200902030222.47644@xxxxxx> <4987B673.8030406@xxxxxxxxxxx>
User-agent: KMail/1.10.3 (Linux/2.6.27.13-ZMI; KDE/4.1.3; x86_64; ; )
On Dienstag 03 Februar 2009 Eric Sandeen wrote:
> you'd need to read the docs for your controller, to find out how to
> tell if it has a writeback cache enabled, and whether it is
> batter-backed or not.

Sorry I didn't write that. Yes it's writeback (can be switched off) and 
it's battery backed. Is there no danger then? Because in the mail from 
Chris, he wrote he got problems because there was "with a write back 
cache enabled on the controller / disks but without barriers". And I 
thought the (not supported/used) barriers could be a problem.

I've re-read the FAQ now. It says it's recommended to turn off barrier 
writes if you have battery-backed writeback, and I guess I'll do that. 
So I misunderstood Chris.
But what about the hard disk cache - should that be disabled? I think in 
case of a power failure, they just loose their cache contents, right? So 
the battery-backed controller cache only helps himself, the disks will 
just throw away up to the 32MB cache they have?

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

<Prev in Thread] Current Thread [Next in Thread>