Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 04 Mar 2004 01:29:26 -0800 (PST) Received: from p15104972.pureserver.info (kettenhemdhuehner.de [217.160.131.79]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i249T1KO017223 for ; Thu, 4 Mar 2004 01:29:02 -0800 Received: from lxkris.int.cinetic.de (grossetto.cinetic.de [217.72.192.194]) (authenticated bits=0) by p15104972.pureserver.info (8.12.6/8.12.6/SuSE Linux 0.6) with ESMTP id i249S741016307 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 4 Mar 2004 10:28:07 +0100 From: Kristian =?iso-8859-15?q?K=F6hntopp?= To: Felipe Alfaro Solana , Robin Rosenberg Subject: Re: Desktop Filesystem Benchmarks in 2.6.3 Date: Thu, 4 Mar 2004 10:28:07 +0100 User-Agent: KMail/1.5.4 Cc: David Weinehall , Andrew Ho , Dax Kelson , Peter Nelson , Hans Reiser , linux-kernel , ext2-devel@lists.sourceforge.net, ext3-users@redhat.com, jfs-discussion@www-124.southbury.usf.ibm.com, reiserfs-list@namesys.com, linux-xfs@oss.sgi.com References: <4044119D.6050502@andrew.cmu.edu> <200403031059.26483.robin.rosenberg.lists@dewire.com> <1078309141.863.3.camel@teapot.felipe-alfaro.com> In-Reply-To: <1078309141.863.3.camel@teapot.felipe-alfaro.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403041028.07235.kris@koehntopp.de> X-archive-position: 2334 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kris@koehntopp.de Precedence: bulk X-list: linux-xfs Content-Length: 1341 Lines: 26 On Wednesday 03 March 2004 11:19, Felipe Alfaro Solana wrote: > The problem is that I couldn't save anything: the XFS volume refused to > mount and the XFS recovery tools refused to fix anything. It was just a > single disk bad block. For example in ext2/3 critical parts are > replicated several times over the volume, so there's minimal chance of > being unable to mount the volume and recover important files. That is a misconception. What is being replicated multiple times in ext2 is the superblock and the block group descriptors. But these are not really needed for recovery (as long as they have default values, which is the case in the vast majority of installations). What is not being replicated is the block allocation bitmap, inode allocation bitmap and the inodes themselves. By running "mke2fs -S" on a ext2 file system, you will rewrite all superblocks, all block group descriptors, and all allocation bitmaps, but leave the inodes themselves intact. You can recreate the filesystem from that with e2fsck, proving that the information from the replicated parts of the file systems is not really necessary. All that e2fsck needs to recover the system is the information from the inodes. If they are damaged (and they are not replicated), the files having inodes in damaged blocks cannot be recovered. Kristian