[Top] [All Lists]

Re: xfs data loss

To: xfs@xxxxxxxxxxx
Subject: Re: xfs data loss
From: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 6 Sep 2009 11:30:41 +0200
In-reply-to: <B9A7B002C7FAFC469D4229539E909760308D8CAB6D@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Organization: it-management http://it-management.at
References: <B9A7B002C7FAFC469D4229539E909760308D8CAB6D@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: KMail/1.10.3 (Linux/; KDE/4.1.3; x86_64; ; )
On Sonntag 06 September 2009 Passerone, Daniele wrote:
> Well, a binary file with 5% data loss would simply not work.
> But I have executables on this filesystem, and they run!

Optimist. It just means the part of the binary you run are not random. 
Randomness of *all* code paths would have to be checked, which you 
probably can't do manually, so binaries are not a good check at all.

Since you didn't change any drives, chances are good that you really 
lost very little data.

> a MB-sized tar.gz file, compression of a postscript file,
> uncompressed perfectly and was visualized in a perfect way by
> ghostview.

That's a good test, so you are lucky.

> Moreover, a device died (a different one) yesterday, and in the
> messages I have ...

Is this on the same controller as the other broken disks were? Then this 
should be it (or it's cabling, or the backplane, etc.). And you should 
immediately shut down the RAID on that controller, as you might loose 
data (or the whole RAID) when the controller writes random data. A 
broken hardware is the worst thing to have. Replace it, test the new 
parts *thouroughly*, and only then start to use the RAID 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

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