fsck.ext4 can't repair block far behind end of the file system

Question

My environment: BananaPI with kernel 3.4.108

Whenever I run a file system check for the SDcard it results with an read error on block 134217729. Actually this is not surprising as this 32GB card has only 7167999 blocks for the second big EXT4 FS.

I also tried to run fsck.ext4 -f -c ( see below ) This didn't help either. It's not a bad block, I think it must be a bad inode which is broken. To answer with "no" for the question to "ignore error" didn't help too.

Obviously fsck.ext4 can find issues on a file system but cannot repair.

My question are there any other non destructive tools available for repairing broken EXT4 fs's with such a problem ?

// Hans

# fsck.ext4 -f -c /dev/sda2
e2fsck 1.42.5 (29-Jul-2012)
Checking for bad blocks (read-only test): done
root: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Error reading block 134217729 (Invalid argument).  Ignore error? yes
Force rewrite? yes
Error writing block 134217729 (Invalid argument) while getting next inode from scan.  Ignore error? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

root: ***** FILE SYSTEM WAS MODIFIED *****
root: 193003/1794048 files (0.3% non-contiguous), 1988723/7168000 blocks

Answer 1

You might try a filesystem editor, like debugfs(8). This is delicate, detail work. But I very much doubt you can fix this, if fsck(8) can't/won't fix the problem, it is probably very severe (or at least outlandish).

Back up the contents of the filesystem. Then you can get a copy of it into a file with dd(1), and fool around with the copy. If you manage to fix it, replay the commands on the original.

Or just back up and reformat.

Check the media, if it is at all dodgy, toss it. The data you store on it is much more valuable.