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