ext4 recovery based on root directory inode
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. |
Quote:
Quote:
|
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. |
Quote:
Code:
mke2fs -n /dev/sdb1 |
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 ) . |
Quote:
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. |
All times are GMT -5. The time now is 03:37 PM. |