From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB54m4tx033800 for ; Sat, 4 Dec 2010 22:48:04 -0600 Received: from greer.hardwarefreak.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A13D31DB6B2D for ; Sat, 4 Dec 2010 20:49:26 -0800 (PST) Received: from greer.hardwarefreak.com (mo-65-41-216-221.sta.embarqhsd.net [65.41.216.221]) by cuda.sgi.com with ESMTP id MvkYblPvNLbb9WWS for ; Sat, 04 Dec 2010 20:49:26 -0800 (PST) Received: from [192.168.100.53] (gffx.hardwarefreak.com [192.168.100.53]) by greer.hardwarefreak.com (Postfix) with ESMTP id 770C36C161 for ; Sat, 4 Dec 2010 22:49:25 -0600 (CST) Message-ID: <4CFB19D5.7010301@hardwarefreak.com> Date: Sat, 04 Dec 2010 22:49:25 -0600 From: Stan Hoeppner MIME-Version: 1.0 Subject: Re: xfs_repair of critical volume References: <75C248E3-2C99-426E-AE7D-9EC543726796@ucsc.edu> <201011121422.28993@zmi.at> <4CDDBC5C.7020708@hardwarefreak.com> (sfid-20101113_121516_584378_2321CE16) <201012041130.20344.Martin@lichtvoll.de> In-Reply-To: <201012041130.20344.Martin@lichtvoll.de> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: xfs@oss.sgi.com 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. -- Stan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs