public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Drake <ddrake@brontes3d.com>
To: tytso@mit.edu
Cc: linux-ext4@vger.kernel.org
Subject: [RESEND e2progs] get_backup_sb: Consider block size when searching for backups
Date: Tue, 29 May 2007 22:26:44 +0100 (BST)	[thread overview]
Message-ID: <20070529212644.B2DE27B409F@zog.reactivated.net> (raw)

I sent this in a few weeks ago, and it hasn't been applied to the hg tree.
Any comments? Thanks.



I've been investigating why e2fsck refuses to restore the backup superblock
of a partition with a broken primary superblock.

The partition in question has a block size of 4096, and mke2fs reports that
backup superblocks were created on blocks 32768, 98304, 163840, ...

When running e2fsck, get_backup_sb starts by guessing a block size of 1024
and backup superblock at block 8193. I'm not sure why, but it actually finds
a superblock at this location, so returns a context with superblock 8193,
blocksize 1024. 

Later on, ext2fs_open2() tries to process this superblock. It then realises
that the block size value stored in the superblock (4096) does not match what
it was told (1024), so it bails out with EXT2_ET_UNEXPECTED_BLOCK_SIZE. fsck
aborts without fixing the partition.

The following patch solves the problem by discounting superblocks which do
not meet the currently-sought block size.
As a result, block 32768 (blocksize=4096) is now used to restore the backup,
which agrees with the first location that mke2fs listed.

This doesn't explain why a superblock backup also appears to exist at
block 8193 (blocksize=1024), which in terms of my real filesystem is actually
offset into block 2048 (blocksize=4096). I assume there is an explanation
for this...

Signed-off-by: Daniel Drake <d.drake@mmm.com>

Index: e2fsprogs-1.39/e2fsck/util.c
===================================================================
--- e2fsprogs-1.39.orig/e2fsck/util.c
+++ e2fsprogs-1.39/e2fsck/util.c
@@ -453,7 +453,8 @@ blk_t get_backup_sb(e2fsck_t ctx, ext2_f
 		if (sb->s_magic == ext2fs_swab16(EXT2_SUPER_MAGIC))
 			ext2fs_swap_super(sb);
 #endif
-		if (sb->s_magic == EXT2_SUPER_MAGIC) {
+		if (sb->s_magic == EXT2_SUPER_MAGIC &&
+		    EXT2_BLOCK_SIZE(sb) == blocksize) {
 			ret_sb = superblock;
 			if (ctx) {
 				ctx->superblock = superblock;

             reply	other threads:[~2007-05-29 21:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-29 21:26 Daniel Drake [this message]
2007-05-29 23:06 ` [RESEND e2progs] get_backup_sb: Consider block size when searching for backups Andreas Dilger
2007-05-31 15:56 ` Theodore Tso

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=20070529212644.B2DE27B409F@zog.reactivated.net \
    --to=ddrake@brontes3d.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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