Sstrhsrtj

Abstract: E2fsck found no error with the -n option but with -p (preen). It corrected the error but did not give any error message. The error is only reflected via exit code. How to interpret this?

I am using an USB hard drive with an Ext2 filesystem to store backups of several machines. Recently I had a huge data throughput on that drive why I decided to do an extra filesystem check. Here are the commands I used (as root) together with their outputs, which also contain the exit status of e2fsck. Unfortunately some phrases are localized to German but the (presumably) important ones are in English:

# e2fsck -nfv /dev/sdb1; echo $?

e2fsck 1.41.1 (01-Sep-2008)

Durchgang 1: Prüfe Inodes, Blocks, und Größen

Durchgang 2: Prüfe Verzeichnis Struktur

Durchgang 3: Prüfe Verzeichnis Verknüpfungen

Durchgang 4: Überprüfe die Referenzzähler

Durchgang 5: Überprüfe Gruppe Zusammenfassung



  709312 inodes used (1.16%)

   95492 non-contiguous inodes (13.5%)

         # von Inodes mit ind/dind/tind Blöcken: 109958/2429/7

96258851 blocks used (39.42%)

       0 bad blocks

       8 large files



  564029 regular files

  121351 directories

       0 character device files

       0 block device files

      11 fifos

  506224 links

   23073 symbolic links (19397 fast symbolic links)

     839 sockets

--------

 1215527 files

0

and

# e2fsck -pfv /dev/sdb1; echo $?



  709312 inodes used (1.16%)

   95492 non-contiguous inodes (13.5%)

         # von Inodes mit ind/dind/tind Blöcken: 109958/2429/7

96258853 blocks used (39.42%)

       0 bad blocks

       8 large files



  564029 regular files

  121351 directories

       0 character device files

       0 block device files

      11 fifos

  506224 links

   23073 symbolic links (19397 fast symbolic links)

     839 sockets

--------

 1215527 files

1

The commands were issued directly one after the other without touching anything else in between. Please note the differences:

• In the second command, the preen option (-p) was used instead of -n.




• The second command reported a different number of "blocks used".




• The commands exited with different exit statuses.

Obviously the preen option (-p) has found (and corrected) a filesystem error that the -n option was not able to find. Unfortunately it does not give any hint about that error in its output.

Now for my questions:

• What error was found and corrected there? Was it as simple as an incorrect count of used blocks?




• What could have caused that error? The filesystem was always cleanly unmounted.




• The filesystem error was corrected by e2fsck. But can I trust the data stored therein? Couldn't it be that whatever caused that filesystem error in the first place, also corrupted the data on the disk? This would render all data on the disk worthless. Or is this to paranoid? Why?

The last question distinguishes between filesystem and data. In this respect, Mikel's answer to "Do journaling filesystems guarantee against corruption after a power failure?" is of high relevance. Unfortunately it focuses on journaling filesystems, so it does not apply to Ext2.

Also Gilles' answer to "How to test file system correction done by fsck" is a good read: According to that, fsck only guarantees a consistent state of the filesystem, not necessarily the latest one.

Update

In his comment, Luciano Andress Martini pointed out that the observed and apparently puzzling behavior of e2fsck could have been caused by RAM errors in the executing machine. While being a highly relevant aspect in comparable situations, it does not seem to apply here: I checked the RAM with "memtest86+" over night and it completed 16 passes without errors. In addition, I performed forced e2fsck -nfv, e2fsck -pfv, and e2fsck -fv runs on the drive under test using another machine (different hardware, kernel, and version of e2fsck). These did not find any filesystem errors and confirmed the stats that were reported by the second e2fsck command described above, in particular the number of used blocks.

You mentioned that this filesystem is used with very old machines. If the filesystem was originally created with a very old mke2fs tool that did not support the resize_inode filesystem feature to reserve some metadata space for on-line extension of the filesystem, it might be possible that your second run with e2fsck version 1.14.1 did just automatically add it.

If I recall correctly, the allocation is completely benign for old systems that don't understand it, but it ensures that some critical metadata structure can extend without a major re-organization, if the filesystem is ever extended.

You can confirm this by running tune2fs -l on the filesystem of your USB drive and on one of the ext2 filesystems of your old machines, and comparing the results. You can do that even if the filesystems are mounted. If the output for your USB drive includes the keyword resize_inode on the Filesystem features: line, and the local ext2 filesystems on your old machines don't have that keyword, then the most likely explanation is that your e2fsck -pfv just took the opportunity to make that tiny allocation in the hope that it might help avoid downtime in the future.