tl;dr; I'm interested into ext4 filesystem tree recovery for corrupted journal inode.
I experienced a hard-drive corruption (an ext4 over LUKS over a WD hard-drive). It was carefully restored from ddrescue (although not completely).
- It can't be mounted as-is (too dirty).
Code: Select all
ext4_ext_map_blocks:4301: inode #8: comm mount: bad extent address lblock: 0, depth: 1 pblock 0
failed to initialize system zone (-117)
- If I do a e2fsck (on a copy of the rescue copy), I see hundreds of thousands of errors of orphaned inodes, among others:
- Entry 'super-important' in / (2) has deleted/unused inode 97518870. Clear<y>? yes
- Entry 'videos' in / (2) has deleted/unused inode 94765075. Clear<y>? yes
- Entry 'books' in / (2) has deleted/unused inode 81002530. Clear<y>? yes
- Entry 'photos' in / (2) has deleted/unused inode 81002531. Clear<y>? yes
- ...
When running dumpe2fs, I get some other information, but detailed information about the journal super block is unavailable:
Code: Select all
dumpe2fs: Corrupt extent header while reading journal super block
So, e2fsck is somehow able to identify:
- inode of files and their content
- inode, filename, and parent directory
- And if I'm myself able to say whether they use to be file, symlinks or directory.
Code: Select all
You got an orphaned inode found: "photos" at 81002531 used to be under "/", e2fsck would drop it under lost+found, but testdisk will link this back to its original place.
Please select: Was is <directory> - <file> - <symlink> - ... ? [select "<directory>"]
Relinking to "/" done.
First, is an ext4 disk layout with this state of corruption (that journal inode #8 and these orphaned directories after e2fsck) still offer a theoretical possibility of recovery?
If yes, could testdisk be in the future, such a salvation tool? If not what am I left with currently?