话题
如果一个文件系统被 e2fsck 成功修复，它保证它处于一致（干净）状态。但是，在修复后评估文件本身的可靠性并不容易。
本题旨在根据标准来判断存储在 ext2 和 ext4 文件系统中的数据的完整性，这些文件系统在特定故障场景中损坏后被修复。
背景
我在外部 USB 硬盘（即基于盘片，无闪存）中使用 ext2 文件系统来备份几台 Linux 机器。为此，我使用选项rw, relatime（总共）手动安装驱动器，因此不sync使用任何选项。
就在最近，在从 openSUSE 13.1 系统（Linux 内核 3.11.6-4）进行大型备份（几个 100 GB）之后，在完成所有对 USB 硬盘的写入活动之后，我无法卸载该驱动器：umount命令被挡住了，没有回来。这同样适用于随后发出的sync命令，该命令进入不间断睡眠（ps状态 D）。
这是当我拔下 USB 硬盘时，它没有释放块。
此后通过标准方式（pm-utils）关闭机器电源的尝试也被卡住了。为了让机器停机，我使用了 SysRq 敬礼r, e, i, s, u, b. 但即使在那里，请求s(sync) 和u(remount read-only) 也没有成功：根据sysrq.c (sysrq.txt) 的内核文档，这些请求在明确宣布它们之前没有完成，其中没有一个他们在这种情况下做到了。因此，当 SysRq b（重新启动）命中时，没有一个已安装的文件系统被确认被完全卸载，最终启动了完全重新启动。
检查所有涉及的文件系统（根分区上的 ext4 和 USB HDD 上的 ext2）e2fsck，我幸运地发现根文件系统是干净的，并且 USB HDD 上的文件系统只显示错误的空闲块和空闲 inode 计数，可以通过 e2fsck 修复。
此处使用的机器的 Systemd 日志没有显示任何与阻止 umount 和同步相关的条目。特别是没有与 IO 问题相关的条目。除了 SysRqs 之外，USB 拔出事件和我的其他措施都已正确记录。
事件发生后对 USB 硬盘执行的SMART 和badblocks测试未发现任何异常。大约 5 个月大的驱动器现在似乎工作正常。
变化
在过去的几年里，我在不同的 USB 硬盘（没有一个超过 16 个月）和运行不同内核版本的不同 Linux 机器上遇到过同样的情况。我处理的唯一偏差是我有时使用电源按钮而不是 SysRq 来关闭机器。
在这些事件中，我检查了所有可能受影响的文件系统（所有 ext2 和 ext4）e2fsck，发现它们都处于以下错误状态之一：
清理文件系统。
e2fsck 可以通过重播日志 (ext4) 来修复不干净的文件系统。
显示错误计数的可用块和可用 inode 的文件系统可以由 e2fsck 纠正。
包含 e2fsck 连接到 lost+found 的孤立 inode 的文件系统。
包含由 e2fsck 克隆的多重声明 inode（由多个文件声明）的文件系统。
实际问题
受上述情况影响并随后被 e2fsck 成功修复的 ext2 或 ext4 文件系统肯定处于一致（干净）状态。
但是该文件系统中文件的内容和元数据呢？
e2fsck 发现的文件系统损坏与数据损坏之间是否存在独特的相关性？例如像：
如果在文件系统中没有发现错误计数以外的其他损坏，则实际文件数据是可以的。
或者：
如果文件系统包含多次声明的 inode，则至少一个文件的内容已损坏。
还是相反：文件系统和文件数据是独立的，因为我们无法从其中一方的损害与另一方的损害中得出结论——至少在不确切了解导致设备通信级别损害的原因的情况下？
在后一种情况下，即使后来发现文件系统是干净的，所描述的场景也可能损坏了文件内容。正确的？
是否有任何经验值或合理的标准可用于根据 e2fsck 发现的文件系统错误来评估文件的完整性？
在这种情况下，Gilles 对“如何测试 fsck 完成的文件系统更正”的回答是一本好书。
文件系统和数据完整性之间的区别也在ext4 文件系统的内核文档中的“数据模式”部分中进行了说明。对于后者，Mikel的出色回答指出了我对“日志文件系统是否保证电源故障后不会损坏？”的出色回答。，这也与这个话题非常相关。
自己的猜测和影响
Systemd 提供服务单元（模板）[email protected]，默认情况下，它会passno在启动时“整理”/etc/fstab 中选择的文件系统。根据-p手册页e2fsck(8)中选项的描述，整理“自动修复 [es] 任何无需人工干预即可安全修复的文件系统问题”。不幸的是，该描述没有指定“安全”是指单独的文件系统一致性还是还包括文件的内容和元数据。
但是，由于此 Systemd 服务以对用户完全透明的方式启动整理，因此至少有一些专家充分信任相应文件系统修复的结果。
因此，基于一种模糊的感觉（！），我会说对于干净的文件系统（上述错误状态 1）以及可以通过重播日志（错误状态 2）来修复的文件系统，可以安全地假设文件本身即使发生此类事件，也不会损坏。
另一方面，对于处于错误状态 5 的文件系统，我会参考备份。
那么，为什么要大惊小怪呢？同意：如果是标准主文件系统或根文件系统，我只会将其内容与最新备份进行比较。但在这种情况下，这些备份位于受影响的 USB 硬盘本身上。如果对其完整性存在疑问，则需要立即再次备份几台机器此外，这会呈现在该驱动器上循环备份策略期间累积的旧备份，否则这些备份可能已用作相应数据的快照， 无意义的。
因此，有一些合理且可靠的标准来确定我们可以在多大程度上信任 ext2 或 ext4 文件系统上的数据，这些数据在受到所述场景影响后被修复。
进一步的发现
试图自己解决这个问题，我在 Oracles System Administration Guide for Sun 中找到了关于 fsck 的精彩章节。尽管它描述了 fsck 的 USF 版本，但总体思路也适用于 e2fsck。但这份非常详细的文档也侧重于 fsck 的使用和文件系统本身，而不是考虑后者的有效负载。
在这个回答“fsck -p (preen) 在 ext4 上做什么？” , Noah 发布了一个文件系统错误列表，这些错误可以通过 fsck 整理 ext4 文件系统和那些不能自动处理的错误进行处理。拥有这样一个文件系统错误列表会很棒，该列表指示其中哪些暗示了文件数据的损坏，哪些暗示了文件数据的损坏——当然只有当这种相关性存在时……
在他的回答中，Michael Prokopec 提到了写缓存对这个问题的重要性。在这方面，我在Tall Jeff 对“正确处理写入缓存的 SATA 磁盘？”的回答中找到了答案。至少大多数 SATA 驱动器默认启用了写入缓存。但是，根据同一篇文章，驱动器会尽可能快地刷新这些缓存。但是当然不能保证...
您可以合理地确定，如果所有检查都通过，则数据是值得信赖的。但是，根据驱动器的使用年限和用例，我会将驱动器克隆到较新的驱动器并使用新驱动器。