我正在处理保存数据缓存的 ext4 非根文件系统的定期损坏问题。缓存专门用于将图像切成碎片，以便以后更容易处理。
应用程序日志中的错误：
OSError: [Errno 74] Bad message: '/redacted/path/to/sliced/image/data'
错误在/var/log/syslog：
kernel: [163197.788364] EXT4-fs error (device md127): ext4_lookup:1590: inode #125532502: comm python3.6: iget: checksum invalid
文件系统位于具有三个 SSD 的 RAID5 阵列上。
之后运行fsck总会解决这个问题，至少到目前为止已经发生了 4-5 次。然而，重新启动正在运行的进程显然是一件令人头疼的事情，并且吞下这个异常（ OSError）并掩盖许多其他问题似乎并不明智。
我能够准确追溯到文件的写入时间（可能是异常发生前的几个小时），但/var/log/syslog当时也没有报告任何问题。
ext4 文件系统损坏的常见原因有哪些？例如，哪些编程错误通常会导致大规模损坏，特别是在 python 中（例如，锁使用不当）？内核或硬件中的错误是否经常导致系统日志中没有错误的损坏？
答案1
这种错误，假设所有错误都是 inode 校验和失败，表示ext4fs模块想元数据已损坏。当然，如果您还看到不同的错误，那么这显然不是答案。
Inode 校验和错误是由某些低级工具或模块（当然不是 Python！）引起的，它与 ext4fs 层关于 inode 结构应该是什么的意见不一致。不更新单个位将导致校验和错误。
整个 inode 的事情发生在内核、文件系统驱动程序和低级文件系统功能之间的接口处——我将其描述为 IOSS，即 I/O 子系统。
这种错误也可能是 IOSS/FS bug（有几年前就发生过这样的事，当 xattr 与校验和冲突时）。因此，如果可能的话，您可能想尝试使用更新的内核/文件系统驱动程序。
答案2
看硬盘驱动器 - 这些 SATA 错误是否危险？ - 询问Ubuntu。我之前在 RAID 阵列中发现了FPDMA QUEUED错误，/var/log/syslog但将其删除，这是这些错误消息的唯一来源。因此，尽管这显然是 ext4 文件系统损坏的常见原因，但它不再是这些错误的解释。