摘要： E2fsck 发现-n选项没有错误，但使用-p(preen)。它更正了错误，但没有给出任何错误消息。该错误仅通过退出代码反映。如何解释这个？
我正在使用带有 Ext2 文件系统的 USB 硬盘驱动器来存储多台机器的备份。最近，我在该驱动器上获得了巨大的数据吞吐量，因此我决定进行额外的文件系统检查。总的来说，我e2fsck用不同的选项进行了四次跑步。以下是我（以 root 身份）使用的命令及其输出，其中还包含e2fsck. 不幸的是，有些短语被本地化为德语，但（可能）重要的是英语：
第一次运行，只读：
# e2fsck -nv /dev/sdb1; echo $?
e2fsck 1.41.1 (01-Sep-2008)
WD-Elements: sauber, 709312/61046784 Dateien, 96258851/244182016 Blöcke
0
第二次运行，只读强制：
# 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
第三次运行，整理：
# e2fsck -pv /dev/sdb1; echo $?
WD-Elements: sauber, 709312/61046784 Dateien, 96258851/244182016 Blöcke
0
第 4 次运行，强制整理：
# 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
命令一个接一个地直接发出，中间没有触及任何其他东西。
请注意差异：
在前两次运行中，文件系统以只读方式打开（
-n选项），而后两次正在整理运行（-p选项）。第一次和第三次运行不是强制的，第二次和最后一次运行是（
-f）。所有运行都报告了一致的文件系统数据，但有一个例外：最后一次运行 (
-pfv) 报告了不同数量的“使用的块”。除了最后一次运行以外的所有运行都以状态 0 退出，最后一次 (
-pfv) 以状态 1 退出。
显然，最后一次强制整理运行 ( -pfv) 发现（并纠正了）其他运行无法找到的文件系统错误。不幸的是，它没有在其输出中给出任何关于该错误的提示。
现在我的问题：
在那里发现并纠正了什么错误？是否像使用过的块数不正确一样简单？
什么可能导致该错误？文件系统总是干净地卸载。
文件系统错误最终由
e2fsck. 但是我可以信任其中存储的数据吗？难道不是首先导致该文件系统错误的任何东西也损坏了磁盘上的数据吗？这将使磁盘上的所有数据一文不值。或者这是偏执狂？为什么？
最后一个问题区分文件系统和数据。在这方面，Mikel对“ Do journaling filesystems保证在电源故障后不会损坏？ ”的回答具有高度相关性。不幸的是，它专注于日志文件系统，因此不适用于 Ext2。
Gilles对“如何测试 fsck 完成的文件系统更正”的回答也很好读：据此，fsck仅保证文件系统的一致状态，不一定是最新状态。
更新 1
Luciano Andress Martini在他的评论中指出，观察到且明显令人费解的行为e2fsck可能是由执行机器中的 RAM 错误引起的。虽然在可比较的情况下是一个高度相关的方面，但它似乎不适用于这里：我用“memtest86+”检查了 RAM 过夜，它完成了 16 次通过而没有错误。此外，我使用另一台机器（不同的硬件、内核和版本）在被测驱动器上执行e2fsck -nfv、e2fsck -pfv和运行。这些没有发现任何文件系统错误，并确认了上次报告的文件系统数据e2fsck -fve2fscke2fsck上面显示的命令，特别是使用的块数。还确认了非强制检查报告的块总数（244182016）。
更新 2
telcoM 的回答表明，观察到的行为e2fsck可以用e2fsck处理非常旧的文件系统时文件系统功能设置的更改来解释。不幸的是，这种非常一致的解释在这里并不适用：文件系统实际上是用更新版本的mke2fs(1.42.8) 创建的，它启用了特性ext_attr, resize_inode, dir_index, filetype, 。上述运行并未改变这一点。sparse_superlarge_filee2fsck
更新 3
同时，USB 驱动器成功通过了无损读写坏块测试（耗时 3 天，是的：指定的块大小（-b）和块数（-c）很重要）和几次离线 SMART 测试。