mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Kristian Köhntopp" <kris@koehntopp.de>
To: Felipe Alfaro Solana <felipe_alfaro@linuxmail.org>,
	Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Cc: David Weinehall <david@southpole.se>,
	Andrew Ho <andrewho@animezone.org>, Dax Kelson <dax@gurulabs.com>,
	Peter Nelson <pnelson@andrew.cmu.edu>,
	Hans Reiser <reiser@namesys.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	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
Subject: Re: Desktop Filesystem Benchmarks in 2.6.3
Date: Thu, 4 Mar 2004 10:28:07 +0100	[thread overview]
Message-ID: <200403041028.07235.kris@koehntopp.de> (raw)
In-Reply-To: <1078309141.863.3.camel@teapot.felipe-alfaro.com>

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


  reply	other threads:[~2004-03-04  9:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-02  4:46 Peter Nelson
2004-03-02  7:23 ` Hans Reiser
2004-03-02 16:34   ` Peter Nelson
2004-03-02 22:33     ` Dax Kelson
2004-03-02 22:47       ` David Weinehall
2004-03-03  1:30         ` Andrew Ho
2004-03-03  1:41           ` David Weinehall
     [not found]             ` <20040303014115.GP19111@khan.acc.umu.se.suse.lists.linux.kernel>
2004-03-03  2:39               ` Andi Kleen
2004-03-03  7:47                 ` Christoph Hellwig
2004-03-03  8:03                   ` Hans Reiser
2004-03-03  8:16                     ` Arjan van de Ven
2004-03-03  9:35                       ` Hans Reiser
2004-03-03  6:00             ` Robin Rosenberg
2004-03-03  9:43               ` Felipe Alfaro Solana
2004-03-03  9:59                 ` Robin Rosenberg
2004-03-03 10:19                   ` Felipe Alfaro Solana
2004-03-04  9:28                     ` Kristian Köhntopp [this message]
2004-03-05  1:59                     ` Clemens Schwaighofer
2004-03-03 10:24                   ` Mike Gigante
2004-03-03 13:14                     ` Felipe Alfaro Solana
2004-03-03 14:16                       ` Hans Reiser
2004-03-03 13:42                   ` Hans Reiser
2004-03-03 10:13                 ` Olaf Frączyk
2004-03-03 13:07                   ` Felipe Alfaro Solana
2004-03-04 14:37                 ` [Jfs-discussion] " Pascal Gienger
2004-03-04 20:43                   ` Per Andreas Buer
2004-03-03  6:30       ` Hans Reiser
2004-03-03 23:41     ` Johannes Stezenbach
2004-03-05 18:46       ` Pavel Machek
2004-03-06  0:16       ` Chris Mason
2004-03-02 17:11 Ray Lee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200403041028.07235.kris@koehntopp.de \
    --to=kris@koehntopp.de \
    --cc=andrewho@animezone.org \
    --cc=david@southpole.se \
    --cc=dax@gurulabs.com \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=ext3-users@redhat.com \
    --cc=felipe_alfaro@linuxmail.org \
    --cc=jfs-discussion@www-124.southbury.usf.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    --cc=pnelson@andrew.cmu.edu \
    --cc=reiser@namesys.com \
    --cc=reiserfs-list@namesys.com \
    --cc=robin.rosenberg.lists@dewire.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®