Hi mates,

I'm trying to recover an ext4 fs after a superblock corruption.
Let me describe what I've got.

1 usb disk of 750GB
2 partition 1: 700+gb, 2: the rest
the first partition contains the corrupt fs.

I tried to use fsck with backup superblock, but no luck.
what I could manage to find is the root directory inode, using a scandrive app.

What's in my mind, having the root dir inode is basically the most important thing, using it I could either reconstruct superblock or iterate through all the inodes and copy data to another fs.

unfortunately I'm not good enough in programming to write a tool for the iteration so I would choose the 1st option, to reconstruct the superblock.

do you guys know , what fields a re required in the superblock to be able to mount it, I guess magic number and state flag would be mandatory, but not sure what else should I fill in?

or if you know a tool which could do the iteration through the inodes using the root directory as a starting point, let me know please.

any help is much appreciated.

thank you!

It seems this is your first post. So, Welcome to LQ!

To do that, may not be complex work, but a certain time-consuming task.

BTW, have you tried running 'fsck' without any switch? This will reread the records and restore them after your 'y' (Yes) replies each prompt.

thank you! nice to meet you .

tried to run fsck without switches, but complains about superblock.

Please describe the cause (or causes) of corruption in order of events, verbosely, how long ago this happened and do include any "repairs" you have tried.


How many backup superblocks did you try? Have you tried finding all alternative superblocks using 'mke2fs -n'? What is the output fsck gives? If you run (a Live CD containing) testdisk on the drive (no partitions mounted and use the "/debug /log" switches to save a log file) you "browse" the partition? ( Proceed > Choose partition table type ("none" because its a partition) > Advanced > Undelete). If that doesn't work look at "testdisk.log" for clues. And what does the drive include? An OS? Just files?

cause:

the disk was attached to a router, running openwrt.
under heavy disk usage, openwrt messes up something, I can see disk read errors, but if I scan the disk attached to a computer, everything seems fine with the disk, no bad sectors.
I guess the issue is due to lack of power in the router's usb port, the disk is just usb powered, no additional power adapter.
Unfortunately it;s not the first time, so I'm considering to buy an active usb hub.
It happened 2 weeks ago, I ran fsck right after the corruption, but didn't help. No other destructive repair was tried, just passive scans for valid part tables, superblock or root dir inodes.

tried to find alternative superblocks with fsck -n, but none of them worked.
testdisk is able to detect partitions, but can't read fs.
I guess fsck messed up all the backup superblocks

here's the log:

Interface Advanced
Geometry from i386 MBR: head=255 sector=63
check_part_i386 failed for partition type 83
check_part_i386 failed for partition type 83
get_geometry_from_list_part_aux head=255 nbr=4
get_geometry_from_list_part_aux head=8 nbr=1
get_geometry_from_list_part_aux head=16 nbr=1
get_geometry_from_list_part_aux head=32 nbr=1
get_geometry_from_list_part_aux head=64 nbr=1
get_geometry_from_list_part_aux head=128 nbr=1
get_geometry_from_list_part_aux head=240 nbr=1
get_geometry_from_list_part_aux head=255 nbr=4
1 P Linux 0 1 1 90499 254 63 1453882437
2 P Linux 90500 0 1 90531 254 63 514080
search_superblock
Couldn't open reiser filesystem
Couldn't open reiser filesystem
Couldn't open reiser filesystem
Change partition type:
1 P Linux 0 1 1 90499 254 63 1453882437
search_superblock
Partition table type (auto): Intel
Disk /dev/sdb - 750 GB / 698 GiB - ADATA HDD CH94
Partition table type: None

Interface Advanced
P Unknown 0 0 1 91201 80 63 1465149168
Change partition type:
P ext4 0 0 1 91201 80 63 1465149168
search_superblock

P ext4 0 0 1 91201 80 63 1465149168
Can't open filesystem. Filesystem seems damaged.

P ext4 0 0 1 91201 80 63 1465149168
Can't open filesystem. Filesystem seems damaged.

the only thing I can see could work is to use that root dir inode as base.

I don't know if it's a reading or typing thing but I said mke2fs as in and (making a backup with 'dd' and) then feeding those superblock numbers to fsck, but since you already ran fsck previously I wouldn't have too much hope wrt the outcome. A last ditch effort may be to re-run 'mke2fs' with the -S switch (see 'man mke2fs') or try your luck carving files with Photorec.

sorry, it was a typing thing.
So I tried to find backup superblock with mke2fs -n -I 128 -m 0 /dev/sdb1 , because i wanted inode size 128 bytes, to be able to mount with different tools on windows box, and don't need reserved area.

Tried the -S, actually this is exactly what I was looking for, but unfortunately didn't work as I expected .
after mke2fs -S -I 128 -m 0 /dev/sdb1 I ran fsck, lot of errors ... , afterwards mounted, but fs is empty.

tried to see where is root dir inode located now, and it's different sector than it was before, so there's no chance to work.
it was either a fake root dir inode detected before, or the fs structure changed somehow.

before mke2fs -S i found root dir inode at sector 41224, and now it's at 41232, quite close , exactly 1 block dif ( having block size 4096 ) .

Maybe I should have explained this right away but the reason for running 'mke2fs -n' is to get diagnostics output in a way that does not alter or deteriorate the state the file system is in any further. Any commands that alter the file system serve only to worsen the problem and any reason for wanting to run altering commands should have been discarded as unwanted. Even though it is your responsibility I'm sorry to see that after failing to heed the warnings twice, after running an uncontrolled fsck you now went for creatively interpreting commands instead of just running what was asked for.
The downside is you just painted yourself in the SNAFU-completely-SOL corner.
The upside is I can now congratulate you with your new paper weight.

I was completely aware of what i was doing, so just took my chance.

I wasn't clear enough I think, I ran the mke2fs -n with those switches because I used those switches when I created the fs, for the reasons enumerated before, sorry for misunderstanding.
the man of mke2fs clearly says to run fsck after mke2fs -S. anuway, the root dir inode being allocated in a different place, the fs wouldn't work without the fsck either.
running fsck, it just overwrote my old root inode with inode bitmap I guess.

Appreciate your help!

Thank you.