情况如下：我有一个（非常旧的）文件系统 - 它创建于 2006 年。它最初是 ext2，后来迁移到 ext3，然后迁移到 ext4，然后迁移到 64 位的 ext4。我最近为其启用了metadata_csum，并且没有遇到任何问题——即使是最旧的数据，在采样时似乎也可以正确检索。文件系统上的例程 fsck 自创建以来已被禁用。由于 HBA 电缆跳跃而导致底层 mdraid 出现轻微的 OOPS 后，我重新组装了 FS，目前正在安装之前对其进行 fscking。一个潜在的问题是 mdraid 重组有稍微进一步的 OOPS，并且该卷在被重新分配（正确的和以前的）元数据 0.90 之前被分配元数据 1.2。结果，从每个底层分区开头开始的约 300 字节到 4096 字节被覆盖。总共 12 个块，假设每个磁盘一个。记住这一点，我正在 fscking fs ：当然第一个超级块被破坏了，但是 fsck 正确地转到了备份超级块并且正在愉快地搅拌。除了大量的错误之外，似乎没有任何错误Inode nnnnn passes checks, but checksum does not match inode. Fix? no。我所说的非常大的数字是指在具有 2.6*10^9 inode 的文件系统上几乎 10^6。鉴于唯一的其他错误小于 20，Inode nnnn contains garbage. Clear? no是否有可能发生的情况是“旧”索引节点的元数据（即启用该功能后未写入的元数据）根本不正确？ 2010 年至 2013 年期间对此进行了很多讨论，然后就消失了。如果是这种情况，我最好的方法是删除该功能，修复其他错误，然后将其添加回来吗？这是一个 40TB 的卷，由于某些原因 (TM)，最后一次备份已经过去了约 18 个月。
作为参考，系统目前运行的是带有最新更新的 Debian 11 amd64。