我们有基于 BBB 的定制主板，它有 256MB RAM 和 4GB 或 eMMC。我们使用 Linux-3.12，在 eMMC 上有 ext4 分区。
我正在编写一个脚本，它会定期运行并检查文件系统错误，如果分区未挂载，我会尝试使用 e2fsck 纠正错误。
最初我用它e2fsck -n /dev/mmcblk0pN (N is partition number)来检查文件系统分区中的错误。
然而，当分区挂载并在分区上创建文件时，上述命令开始给出错误的结果。
现在我需要一种替代方法来检查文件系统错误，
一种选择是使用tune2fs -l该分区上的命令检查Filesystem state字段。
现在我不确定这个字段是否可靠，可以检查文件系统错误？这个字段可能有哪些值？我已经看到了它的值clean，clean with errors但not clean我没有从手册页获得更多信息。
那么，tune2fs -l /dev/mmcblk0pN | grep “Filesystem state” | grep “error”检测文件系统错误可靠吗？还有其他更好的选择来检查分区中的文件系统错误吗？
有什么建议/指示/信息吗？
答案1
“Tune2fs -l” 会告诉您内核在运行时是否注意到了文件系统损坏问题。例如，如果您要求 ext4 删除一个文件，并且 ext4 发现该文件中的某些块已被标记为已释放，则意味着分配位图已损坏。请注意，当 ext4 发现它时，分配位图已经损坏。事实上，它可能已经损坏了几天或几周，如果您一直在写入新文件，则 ext4 可能会为新文件分配用于旧文件的块，因此用户可能会丢失数据。
唯一可靠地确定文件系统是否一致或可能存在一定程度损坏的方法是运行 e2fsck。执行此操作需要卸载文件系统或创建只读快照。（如果您使用的是 LVM，则可以创建只读快照，检查只读快照，然后如果发现文件系统已损坏，则可以重新启动系统并让 e2fsck 修复文件系统，或者向系统管理员发送电子邮件以安排停机时间来修复文件系统。）
综上所述，如果文件系统已损坏，最常见的情况可能是由于硬件问题。这可能是由于内核错误造成的，尽管我确实会定期对稳定内核（而不仅仅是上游内核）进行回归测试，而且我们很长时间没有遇到文件系统损坏问题了。设备驱动程序中可能存在内存损坏错误，并且 (a) 设备驱动程序不在上游，硬件供应商没有进行适当的质量控制，或者 (b) 错误已在上游修复，甚至已推送到最新的稳定内核，但设备内核没有从稳定内核系列中获取更新。
请注意，如果您要查看文件系统是否因为内核遇到明显错误而损坏，您不必只抓取 dmesg 或 /var/log/messages。您还可以尝试读取文件 /sys/fs/ext4//first_error_time。如果该文件包含非零值，它将告诉您内核检测到文件系统损坏的时间（使用 Unix 纪元）。该目录中的 errors_count 文件将告诉您检测到了多少文件系统损坏（但这可能只是系统一遍又一遍地遇到相同的问题）。同样有趣的是，如果您想测试系统如何处理内核检测到的文件系统错误，您可以尝试将字符串写入 trigger_fs_error 文件 --- 例如，echo "test error" > /sys/fs/ext4/sda1/trigger_fs_error"
最后，请查看 tune2fs 中可以设置的错误行为旋钮。如果您真的想确保在检测到文件系统损坏问题后不会造成更多损害，那么您可能需要将文件系统配置为在发现问题时重新以只读方式安装 --- 或者可能只是强制重新启动，以便可以在启动过程中运行 e2fsck 以在（甚至更多）用户数据损坏或丢失之前解决问题。