e2fsck没有说的是什么？

Question

摘要: E2fsck没有发现-n选项出错，但发现-p (preen)错误。它纠正了错误，但没有给出任何错误消息。错误仅通过退出代码反映。如何解读这一点？

我使用带有Ext2文件系统的USB硬盘存储多台计算机的备份。最近，我在这个驱动器上获得了巨大的数据吞吐量，所以我决定进行额外的文件系统检查。总之，我用不同的选项运行了四次e2fsck。下面是我使用的命令(作为根命令)及其输出，这些命令还包含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

第四轮，强制整容：

# 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最终纠正了文件系统错误。但我能相信里面储存的数据吗？难道一开始是什么导致了文件系统错误，也破坏了磁盘上的数据吗？这将使磁盘上的所有数据变得毫无价值。或者这是妄想狂？为什么？

最后一个问题是区分文件系统和数据。在这方面，米克尔的回答 to "日志文件系统是否保证在电源故障后防止损坏？“具有很高的相关性。不幸的是，它关注的是日志记录文件系统，因此它不适用于Ext2。

吉尔斯的回答 to "如何测试fsck所做的文件系统校正“也是一个很好的读物:根据这一点，fsck只保证文件系统的一致状态，而不一定是最新的状态。

更新1

在他的评论中，卢西亚诺·安德莱丝·马蒂尼指出，e2fsck的观察和显然令人费解的行为可能是由执行机器中的内存错误引起的。虽然在类似的情况下，它是一个高度相关的方面，但在这里似乎不适用:我整晚用"memtest86+“检查内存，它完成了16次传递，没有出错。此外，我使用另一台机器(不同的硬件、内核和e2fsck版本)在正在测试的驱动器上运行e2fsck -pfv、D43和e2fsck -fv。这些代码没有发现任何文件系统错误，并确认了上面显示的最后一个e2fsck命令报告的文件系统数据，特别是使用的块数。此外，非强制检查报告的区块总数(244182016)也得到了确认。

更新2

电讯公司的答覆建议，e2fsck的观察到的行为可以通过e2fsck在处理非常老的文件系统时所做的文件系统特性设置的更改来解释。不幸的是，这个非常一致的解释并不适用于这里:文件系统实际上是用较新版本的mke2fs (1.42.8)创建的，该版本启用了ext_attr、resize_inode、dir_index、filetype、sparse_super、large_file等特性。上面描述的e2fsck运行没有改变这一点。

更新3

同时，USB驱动器成功地通过了非破坏性读写块测试(耗时3天，是的:指定块大小(-b)和块数(-c)物质批次)和几个离线S.M.A.R.T.测试。

Answer 1

您提到了这个文件系统与非常老的机器一起使用。如果文件系统最初是用一个非常老的mke2fs工具创建的，该工具不支持resize_inode文件系统特性，以便为文件系统的在线扩展保留一些元数据空间，那么您使用e2fsck 1.14.1版运行的第二次运行可能会自动添加它。

如果我没记错的话，这种分配对于那些不理解它的旧系统来说是完全良性的，但是它可以确保一些关键的元数据结构可以在不进行重大重组的情况下扩展，如果文件系统被扩展的话。

您可以通过在USB驱动器的文件系统和旧计算机的tune2fs -l文件系统上运行ext2来确认这一点，并对结果进行比较。即使安装了文件系统，也可以这样做。如果您的USB驱动器的输出包括Filesystem features:行上的关键字D5，而旧机器上的本地ext2文件系统没有该关键字，那么最有可能的解释是，您的e2fsck -pfv只是利用这个机会进行了这种微小的分配，希望它有助于避免将来的停机时间。

Answer 2