ext4 filesystem still has errors after fsck

Question

Suddenly my ext4 file system fell down into read-only mode. I've unmounted this disk and tried to repair it, but without any success.

1. fsck tries to fix something but ends with FILE SYSTEM WAS MODIFIED, WARNING: Filesystem still has errors.
2. mount fails with failed: Structure needs cleaning message.
3. badblocks tool shows several errors.
4. smartctl test status: read failure.

Also, I've made disk image via ddrescue tool, but can't repair/mount partition from it as from HDD.

What I want:

1. Mount partition and copy not damaged files.
2. Make decision - does this HDD has physical problems, or this is only ext4 crash?

Solution

If the badblocks tool shows several errors and smartctl is reporting errors, then it indicates you definitely have some kind of HDD problem. So you need to address that first.

The most conservative thing you can do is to use ddrescue to get two disks that are at least as big as your hard drive. I'm going to call your original disk ORIG, and the two disks DISK_A and DISK_B. First use ddrescue to make a copy from ORIG to DISK_A. Then use ddrescue to make a copy from DISK_A to DISK_B. Why make copies right away? Because if your hard drive is failing (and your report that badblocks shows errors is a strong indication there are errors), you want to make a copy right away before more sectors fail. (Sometimes hard drives have cascade failures where initially it's only a handful of sectors that go bad; but then more and more sectors can start going bad if the problem was due to a head crash kicking up debris into the sealed chamber, and then when debris impacts the heads, they crash into the platters again, damaging more sectors, and kicking more debris... repeat until the disk is dead as a doornail.)

Why make a second copy from DISK_A to DISK_B? Because you'll try various recovery techniques on DISK_B, and if they end up causing logical damage, you can always go back to DISK_A, and copy the original disk image on DISK_B (or maybe even DISK_C) so you can always have a fallback in case a particular recovery technique makes things worse or you hope that some other technique might recover more data.

It is likely that e2fsck -fy will be able to completely fix the file system image on DISK_B. If it can't, it's likely a bug in e2fsck. Please see the REPORTING BUGS section of the e2fsck manual for more information about what is needed for a useful bug report. (Also give information about your hardware and what you've done to rule out hardware problems --- making a copy of the file system image to new disk is a great way of doing this.)

Comments

[mangup]

Theodore, I've made an image (via ddrescue) and tried to repair (fsck) it. But no luck. Was it valid action?

[Theodore Ts'o]

Stack exchange is probably not the right place to be discussing this, because there's not enough room for all of the details necessary to figure out exactly what you've done. Did you follow exactly what I suggested above? Can you make a copy of the initial copy, and then run fsck on the copy, saving the output to a file and sending the output to the [email protected] mailing list?