xfs
[Top] [All Lists]

Re: xfs_repair of critical volume

To: xfs@xxxxxxxxxxx
Subject: Re: xfs_repair of critical volume
From: Martin Steigerwald <Martin@xxxxxxxxxxxx>
Date: Sat, 4 Dec 2010 11:30:19 +0100
In-reply-to: <4CDDBC5C.7020708@xxxxxxxxxxxxxxxxx>
References: <75C248E3-2C99-426E-AE7D-9EC543726796@xxxxxxxx> <201011121422.28993@xxxxxx> <4CDDBC5C.7020708@xxxxxxxxxxxxxxxxx> (sfid-20101113_121516_584378_2321CE16)
User-agent: KMail/1.13.5 (Linux/2.6.37-rc3-tp42; KDE/4.5.3; i686; ; )
Am Freitag 12 November 2010 schrieb Stan Hoeppner:
> Michael Monnerie put forth on 11/12/2010 7:22 AM:
> > I find the robustness of XFS amazing: You overwrote 1/5th of the disk
> > with zeroes, and it still works :-)
> 
> This isn't "robustness" Michael.  If anything it's a serious problem.
> XFS is reporting that hundreds or thousands of files that have been
> physically removed still exist.  Regardless of how he arrived at this
> position, how is this "robust"?  Most people would consider this
> inconsistency of state a "corruption" situation, not "robustness".

I think its necessary to differentiate here:

1) It appears to be robustness - or pure luck - regarding metadata 
consistency of the filesystem. I tend to believe its pure luck and that XFS 
just stored the metadata on the other RAID arrays.

2) XFS does not seem to have a way to detect whether file contents are 
still valid and consistent. It shares that with I think every other Linux 
filesystem instead BTRFS which uses checksumming for files. (Maybe NILFS as 
well, I don't know, and the FUSE or the other ZFS port).

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

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