public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@turbolabs.com>
To: Thomas Capricelli <tcaprice@logatique.fr>
Cc: linux-kernel@vger.kernel.org
Subject: Re: fs corruption recovery?
Date: Wed, 9 Jan 2002 03:43:46 -0700	[thread overview]
Message-ID: <20020109034346.H769@lynx.adilger.int> (raw)
In-Reply-To: <3C3BB082.8020204@fit.edu> <20020108200705.S769@lynx.adilger.int> <20020109092659.2907323CBB@persephone.dmz.logatique.fr>
In-Reply-To: <20020109092659.2907323CBB@persephone.dmz.logatique.fr>; from tcaprice@logatique.fr on Wed, Jan 09, 2002 at 10:28:57AM +0100

On Jan 09, 2002  10:28 +0100, Thomas Capricelli wrote:
> On Wednesday 09 January 2002 04:07, Andreas Dilger wrote:
> > Try "e2fsck -B 4096 -b 32768 <device>" instead.
> 
> I thought e2fsck was already trying the different superblocks present on the 
> device.

Well, yes and no.  Most versions of e2fsck (i.e. every version in existence
unless you have a very recent copy from Ted's BitKeeper repository) will
try possible block sizes, but will not try different block numbers.

> Why isn't e2fsck smart enought to look for then? Is this an intended purpose?

Well, in the most recent versions, it will try a lot harder to try and find
backup superblocks.  It will still not run e2fsck automatically on the device.
There are many reasons why e2fsck may think the superblock is corrupted, but
in fact it isn't:

1) superblock has a new feature which an old e2fsck doesn't understand
2) filesystem is no longer ext2, but may still have the backup superblock
   (e.g. you mkswap on an old ext2 partition, it leaves the old superblock)

> Why do you use the -B option ? How can it be useful to force the block size?
> Especially if this one is different. 

Well, since it is possible to have multiple block sizes for ext2, if you
specify "-b 32768" (i.e. block 32768) for the superblock backup, how does
it know what the blocksize is if you don't tell it that also*.  The old
error message (try -b 8193) assumes that you have a 1kB blocksize.  All
ext2 filesystems larger than 500MB made in the last couple of years really
have 4kB blocksize** so e2fsck is far more likely to find a superblock
backup at 4kB * 32768 than at 1kB * 32768 (especially since there will
never be a backup at 1kB * 32768, but rather 1kB * 32769, and only on
_really_old_ non-sparse ext2 filesystems).

Cheers, Andreas

*) OK, that is a bit of a lie, e2fsck appears to check all valid blocksizes
   when a block number is given, but since one can assume it is a 4kB
   block size, you may as well specify it.
**) 4kB blocks provide _much_ better performance than 1kB blocks, even if
   they waste more space, and also allow for larger filesystems.
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/


      reply	other threads:[~2002-01-09 10:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-09  2:52 fs corruption recovery? Kervin Pierre
2002-01-09  3:07 ` Andreas Dilger
2002-01-09  3:26   ` Richard Gooch
2002-01-09  4:14     ` Kervin Pierre
2002-01-09  5:29       ` Richard Gooch
2002-01-09 11:10       ` Walter Hofmann
2002-01-10 15:50       ` Ralf Baechle
2002-01-09 10:24     ` Helge Hafting
2002-01-09 15:12       ` Richard Gooch
2002-01-09 15:22         ` Roy Sigurd Karlsbakk
2002-01-09 12:26     ` Bjorn Wesen
2002-01-09 20:29     ` Alex Bligh - linux-kernel
2002-01-09  4:03   ` Kervin Pierre
2002-01-09  5:20     ` H. Peter Anvin
2002-01-09  9:28   ` Thomas Capricelli
2002-01-09 10:43     ` Andreas Dilger [this message]

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=20020109034346.H769@lynx.adilger.int \
    --to=adilger@turbolabs.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tcaprice@logatique.fr \
    /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