Re: xfs_repair of critical volume

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5 Dec 2010, at 04:49, Stan Hoeppner wrote:

> Martin Steigerwald put forth on 12/4/2010 4:30 AM:
>> 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).
> 
> After re-reading my own words above again, I feel I a need to clarify
> something:  I took exception merely to the description of "robustness"
> being used in this situation.  I was not and am not being derogatory of
> XFS in any way.  I love XFS.  Of all available filesystems (on any OS) I
> feel it is the best.  That's why I use it. :)
> 
> In this scenario, other filesystems may have left the OP empty handed.
> So, I guess XFS deserves deserves a positive attribution for this.  But,
> again, I don't think "robustness" is the correct attribution here.

I think 'lucky' is probably a more appropriate term. The chances are that due to the size of the array, all the inodes and the inline extent lists were on the first volume. If' he'd lost that instead, everything would be gone.

--
Roger

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs


[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux