7

I recently had a corrupted ext4 file system throwing these errors:

kubuntu@kubuntu:~$ sudo mount -t ext4 /dev/sdc2 c1
mount: wrong fs type, bad option, bad superblock on /dev/sdc2,
  missing codepage or helper program, or other error
  In some cases useful info is found in syslog - try
  dmesg | tail  or so

kubuntu@kubuntu:~$ sudo fsck.ext4 -v /dev/sdc2
e2fsck 1.42.5 (29-Jul-2012)
    fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/sdc2
Could this be a zero-length partition?

kubuntu@kubuntu:~$ dmesg | tail
[ 2684.532855] Descriptor sense data with sense descriptors (in hex):
[ 2684.532858]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 2684.532876]         05 3f c8 b0 
[ 2684.532885] sd 5:0:0:0: [sdc]  
[ 2684.532893] Add. Sense: Unrecovered read error - auto reallocate failed
[ 2684.532898] sd 5:0:0:0: [sdc] CDB: 
[ 2684.532902] Read(10): 28 00 05 3f c8 b0 00 00 08 00
[ 2684.532917] end_request: I/O error, dev sdc, sector 88066224
[ 2684.532927] Buffer I/O error on device sdc2, logical block 22
[ 2684.532973] ata6: EH complete

After recovering the partition with e2fsck -f -b 32768, I've noticed that the oldest files on the disk were mostly preserved, and that most of the unrecovered files were the newest files, and thus without backups.

Is the property of losing the newest files and preserving the oldest files intrinsic to ext4, or was this just bad luck? Are there any file systems which, upon corruption, tend to lose the older files and to preserve the newer ones?

  • 1
    Came here from your original post; disappointed to see there's no answer yet. I'm in a very similar boat! – EnemyBagJones Aug 4 '17 at 14:56
  • How old is "old" and how new is "new"? – Kusalananda Nov 27 '17 at 11:16
  • If it's an I/O error from the drive itself, it probably has nothing to do with the file system. And if there just so happens to be a section of the drive that is faulty and unuseable, you'd see it when you try to use it, i.e. with newer files... – ilkkachu Nov 27 '17 at 11:16
  • 1
    @Kusalananda: The "old" files are the files that have been on the disk the most amount of time. In my specific case, it was probably about 2-3 years. The "new" files are files that have been on the disk the least amount of time, less than three months. – dotancohen Nov 27 '17 at 11:19
  • 3
    If your drive or filesystem develops a problem writing (but not reading), you see it on the parts you write after the problem shows up. So 1) check your drive for errors (smartmontools) and 2) if SMART is OK then check the filesystem (fsck). – xenoid Nov 27 '17 at 11:34
2
+50

Partial answer:

The superblock on your filesystem had become unreadable. The superblock is the most important block, because it contains the information how the filesystem is set up.

All newer filesystem use a so-called journal: new or changed blocks are written to some contigous area first, and eventually replace the blocks in the "normal" area. This makes recovery easier: the recovery program looks at the journal, checks what transactions were complete before the failure, and then can restore the filesystem to a consistent state from the last successful transaction. This also means that the newest changes are lost after a recovery, but usually these are only small changes.

It's difficult to say what happened in your case because you didn't give information about how the recovery process went. The filesystem contains copies of the superblock, so you should have been able to use a copy instead of the corrupted one, access the journal from the copy, and restore the filesystem to nearly the same state you had before the problem.

As you said you lost quite a few newer files, my guess is that the recovery program either couldn't restore the superblock, and therefore made some assumptions, and because of that or because of some other reason couldn't find the journal, so you lost all changes in the journal, instead of just the last incomplete transaction.

In general, newer filesystem like ext4 are better at recovery (possibly with some manual input during recovery) than older filesystems like ext2 or FAT. If these get corrupted, you loose whatever was corrupted. In journaled filesystems, it's nearly always possible to move back to some consistent state that's not too far away from the state when the problem occured. So the answer to the question in the subject is "not at all, quite the contrary".

You can use mount options to influence how often and in what way the journal is written and transactions are commited, so you can trade increased recovery chances for performance.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.