我们可以信任e2fsck修复的文件系统中的文件吗？

话题

如果文件系统已通过e2fsck成功修复，则可以确保其处于一致（干净）状态。但是，修复后评估文件本身的可靠性并不容易。

这个问题的目标是判断存储在ext2和ext4文件系统中的数据的完整性的标准，这些文件系统在特定故障情况下损坏后就得到了修复。

背景

我在外部USB HDD（即基于磁盘，无闪存）中使用ext2文件系统来备份多台Linux机器。为此，我使用选项rw, relatime（总共）手动安装驱动器，因此不sync使用任何选项。

就在最近，从openSUSE 13.1系统（Linux内核3.11.6-4）进​​行了大备份（几百GB）之后，并且完成了对USB HDD的所有写操作之后，我无法卸载该驱动器：umount命令被阻止，没有返回。相同的情况适用于随后发出的sync命令，该命令进入了不间断的睡眠（ps状态D）。

这是我拔下未释放模块的USB HDD的时候。

此后尝试通过标准方式（pm-utils）关闭机器电源的尝试也陷入了困境。为了使机器停机，我用了SysRq的敬礼r，e，i，s，u，b。但是即使在那儿，请求s（同步）和u（重新挂载只读）也没有成功：根据sysrq.c（sysrq.txt）的内核文档，这些请求在它们明确声明are之前没有完成。他们在这种情况下做到了。因此，在SysRq b（重新引导）命中后，确认没有一个已挂载的文件系统被完全卸载，这最终启动了完全重新引导。

e2fsck幸运的是，通过检查所有涉及的文件系统（根分区上的ext4和USB HDD上的ext2），我发现根文件系统是干净的，而USB HDD上的文件系统仅显示了错误的可用块数和可用inode数，可以通过e2fsck进行修复。

此处使用的计算机的Systemd日志未显示与阻止umount和同步相关的任何条目。特别是，没有与IO问题相关的条目。USB拔出事件和除SysRqs之外的其余措施均已正确记录。

badblocks事件发生后，SMART和在USB HDD上执行的测试均未发现任何异常。该驱动器大约有5个月的使用寿命，现在看来可以正常工作。

变化

在过去的几年中，我多次遇到相同的情况，它们使用不同的USB HDD（都不超过16个月），并且在运行不同内核版本的Linux机器上。我治疗的唯一偏差是我有时使用电源按钮而不是SysRq来关闭机器。

在这些事件中的每一个事件中，我都使用来检查所有可能受影响的文件系统（所有ext2和ext4）e2fsck，并找到所有处于以下错误状态之一的文件系统：

1. 清理文件系统。

2. e2fsck可以通过仅重播日志（ext4）来修复不干净的文件系统。

3. 文件系统显示了可用块和可用索引节点的错误计数，可以通过e2fsck进行更正。

4. 包含孤立的inode的文件系统，e2fsck连接到lost + found。

5. 包含由e2fsck克隆的多声明索引节点（由多个文件声明）的文件系统。

实际问题

受上述情况影响并随后被e2fsck成功修复的ext2或ext4文件系统肯定处于一致（干净）状态。

但是该文件系统中文件的内容和元数据呢？

e2fsck发现的文件系统损坏与数据损坏之间是否存在独特的关联？例如：

如果在文件系统中没有发现错误计数以外的其他损坏，那么实际的文件数据就可以了。

或者：

如果文件系统包含多索取的inode，则至少一个文件的内容已损坏。

还是相反：文件系统和文件数据是相互独立的，只要它们不能从一个对另一个的损害中得出结论-至少在没有确切了解造成设备通信级别损害的原因的情况下？

在后一种情况下，即使后来发现文件系统是干净的，所描述的情况也可能损坏了文件内容。正确的？

是否有任何经验值或合理的准则可用来评估文件的完整性，具体取决于e2fsck发现的文件系统错误？

在这种情况下，Gills对“如何测试由fsck完成的文件系统更正”的答案是很好的读物。

ext4文件系统的内核文档中的“数据模式”部分也介绍了文件系统与数据完整性之间的区别。对于后者，我得到了Mikel的出色回答：“日记文件系统是否可以保证在电源故障后不会损坏？” ，这也与此主题非常相关。

自己的猜测和影响

Systemd提供服务单元（模板）systemd-fsck @ .service，默认情况下，它会passno在启动时“自定义”在/ etc / fstab中选择的文件系统。根据-p手册页e2fsck（8）中对选项的描述，自定义“自动修复可以在没有人工干预的情况下安全修复的任何文件系统问题”。不幸的是，该描述未指定“安全”是仅指文件系统一致性，还是还包括文件的内容和元数据。

但是，由于此Systemd服务以对用户完全透明的方式启动整理，因此至少有一些专家充分信任相应文件系统修复的结果。

因此，基于模糊的感觉（！），我想说的是，对于干净的文件系统（上述错误状态1），可以通过仅重播日志来修复（错误状态2），因此可以安全地假设文件本身即使发生此类事件也不会损坏。

另一方面，对于处于错误状态5的文件系统，我将引用备份。

那么，为什么这么大惊小怪呢？同意：对于标准的家庭文件系统或根文件系统，我将其内容与最新备份进行比较。但是在这种情况下，这些备份本身在受影响的USB HDD上。如果对它们的完整性有疑问，则需要立即再次备份多台计算机。此外，这将提供较旧的备份，这些备份是在该驱动器上的循环备份策略期间累积的，否则可以用作对应数据的快照。 ， 无意义的。

因此，对于在受上述情况影响后修复的ext2或ext4文件系统上，我们可以信任多远的数据拥有一些合理且可靠的标准将非常有用。

进一步的发现

为了自己解决该问题，我在《 Oracle Sun系统管理指南》中找到了有关fsck的出色章节。尽管它描述了fsck的USF版本，但一般思想也适用于e2fsck。但是，这个非常详细的文档也侧重于fsck和文件系统本身的用法，而不是考虑后者的有效负载。

在对“ fsck -p（preen）在ext4上做什么”的回答中？，Noah发布了一个文件系统错误列表，这些文件系统错误可以通过fsck整理ext4文件系统来自动处理，而那些不能解决。最好有这样一个文件系统错误列表，它指出其中哪些还暗示着文件数据损坏，哪些不暗示—当然，只有在存在这种关联的情况下...

在他的回答中，Michael Prokopec提到了写入缓存对这个问题的重要性。在这方面，我在高个子杰夫（Tall Jeff）的回答中发现：“可以正确处理写缓存的SATA磁盘？” 默认情况下，至少大多数SATA驱动器已启用写缓存。但是，根据同一篇文章，驱动器试图尽快刷新这些缓存。但是当然不能保证...