Subj : Re: e2fs corrupted superblock
To   : comp.os.linux
From : Thomas D. Shepard
Date : Sat Jul 31 2004 07:56 pm

On Thu, 29 Jul 2004 21:56:01 -0700, Thomas D. Shepard wrote:

Here is a follow-up on the post I did this morning.
Hopefully some of this will help you.

Note that I am assuming an ext2 or ext3 filesystem.

As root, I execute dd to examine the raw data in /dev/hde1, which happens
to be my boot partition. It is currently mounted, but I am quite sure the
results would be exactly the same if it weren't. Luckily, I already know
the block size is 1024, but man mke2fs will show your the best things to
guess. I skip over the boot block using "skip=1".

root@main[5] dd if=/dev/hde1 bs=1024 count=1 skip=1 > testblock

Now I can open the file "testblock" in emacs and switch to hexl mode. It
looks like this:

00000000: f865 0000 c797 0100 6314 0000 ca57 0100  .e......c....W..
00000010: c165 0000 0100 0000 0000 0000 0000 0000  .e..............
00000020: 0020 0000 0020 0000 d807 0000 6f1e 0441  . ... ......o..A
00000030: 6f1e 0441 a000 ffff 53ef 0100 0100 0000  o..A....S.......
00000040: 8aa0 6a3f 0000 0000 0000 0000 0100 0000  ..j?............
00000050: 0000 0000 0b00 0000 8000 0000 0400 0000  ................
00000060: 0600 0000 0100 0000 6dd6 e94e 1b67 4341  ........m..N.gCA
00000070: b7dc 9ef9 d378 607c 2f62 6f6f 7431 0000  .....x`|/boot1..
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000e0: 0800 0000 0000 0000 0000 0000 0e60 a07d  .............`.}
000000f0: d9db 4a3b 9406 dbe1 79ca 893c 0200 0000  ..J;....y..<....
00000100: 0000 0000 0000 0000 8aa0 6a3f 0000 0000  ..........j?....
....(the remainder is a bunch of zero bytes)...

This is the superblock. If it were corrupt but still had recognizable
information in it, I might be able to fix it just by guessing the missing
data. Also, I could change the skip value to look at another copy of the
superblock. Another post talks about one of your backup superblocks, so I
assume you don't need me to talk about how to figure out where the backup
superblocks are.

I don't know what the dumpe2fs command will do if the superblock is
corrupt. (If nobody reading this knows and anyone is curious, I might make
a test filesystem or something and experiment by deliberately corrupting
the superblock. In fact, that would be a great way for you to practice
before trying to recover your data.) Maybe it is smart enough to find the
backup superblocks or can be told where they are?

Anyway, I now have the raw data, and its meaning should be as follows:

number of inodes - 4 bytes
number of blocks - 4 bytes
num reserved blocks - 4 bytes
num free blocks - 4 bytes
num free inodes - 4 bytes
first data block - 4 bytes
block size (sort of) - 4 bytes (log base 2 of block size, usually)
fragment size - 4 bytes
blocks per group - 4 bytes
fragments per group - 4 bytes
inodes per group - 4 bytes
mount time - 4 bytes
last modification time - 4 bytes
mount count - 2 bytes
max mount count - 2 bytes
ext2 signature - 2 bytes
status - 2 bytes
error handling - 2 bytes
minor revision - 2 bytes
time last checked - 4 bytes
max check time interval - 4 bytes
operating system - 4 bytes
file system revision - 4 bytes
UID - 2 bytes
GID - 2 bytes

(I got this from "Linux Kernel Programming," Beck et al., Addison Wesley,
third edition. But there are many other places you can find it.)

Now I will run dumpe2fs on it

root@main[9] dumpe2fs /dev/hde1
dumpe2fs 1.34 (25-Jul-2003)
Filesystem volume name:   /boot1
Last mounted on:          <not available>
Filesystem UUID:          6dd6e94e-1b67-4341-b7dc-9ef9d378607c
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal filetype needs_recovery sparse_super
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              26104
Block count:              104391
Reserved block count:     5219
Free blocks:              88010
Free inodes:              26049
First block:              1
Block size:               1024
Fragment size:            1024
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         2008
Inode blocks per group:   251
Filesystem created:       Thu Sep 18 23:22:02 2003
Last mount time:          Sun Jul 25 13:56:15 2004
Last write time:          Sun Jul 25 13:56:15 2004
Mount count:              160
Maximum mount count:      -1
Last checked:             Thu Sep 18 23:22:02 2003
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:		  128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      0e60a07d-d9db-4a3b-9406-dbe179ca893c


Group 0: (Blocks 1-8192)
  Primary superblock at 1, Group descriptors at 2-2
  Block bitmap at 3 (+2), Inode bitmap at 4 (+3)
  Inode table at 5-255 (+4)
  0 free blocks, 1974 free inodes, 2 directories
  Free blocks: 
  Free inodes: 30-32, 35-43, 47-2008
Group 1: (Blocks 8193-16384)
  Backup superblock at 8193, Group descriptors at 8194-8194
  Block bitmap at 8195 (+2), Inode bitmap at 8196 (+3)
  Inode table at 8197-8447 (+4)
  4968 free blocks, 2008 free inodes, 0 directories
  Free blocks: 11417-16384
  Free inodes: 2009-4016
....(lots of other groups)...

As a sanity check, I can spot check a few things to verify that the data
in my "testblock" file really is the superblock. For example, dumpe2fs
claims there are 26104 inodes. The first 4 bytes of data in my testblock
file are f8 65 00 00. Since my x86 cpu is little-endian and byte
addressable, this is interpreted as

0x65f8 = 26104 in base 10

This is indeed the superblock.

So now, after carefully consulting the man and/or info pages on dd,
mke2fs, dumpe2fs, and possibly other commands, you should be able to
figure out how to extract one of the good backup superblocks and re-write
it at the location of the first superblock.

I would love to carry this out in detail and post, but this post is
already way too long.

-- 
Thomas D. Shepard
Sorry, you can't email me.
(Email address is fake.)

.