我在 64 位 ArchLinux（内核 5.4.50）上使用 e2fsprogs 1.45.6-2 将硬盘格式化为 EXT4，并在其中填充数据。之后，我将其安装到另一台运行 32 位 Debian Jessie（内核 3.16.84-1）的计算机上，并使用 e2fsprogs 1.42.12-2+deb8u2，并将一个文件复制到其中。
这个版本差异是否存在问题并且可能导致文件系统损坏？
在 32 位 Jessie 系统关闭期间，我注意到一个 e2fsck 错误消息，该消息基本上表明它由于 metadata_csum 而无法运行。
因此我谷歌了一下，发现元数据校验和是在 1.43 中引入的： https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
让我感到非常不舒服的是下面这句话...... 旧的 fs 代码不可能写入启用了元数据校验和的文件系统。metadata_csum 标志被实现为 ROCOMPAT 标志，这应该可以防止（非恶意的）旧程序搞乱事情。
我原本以为如果存在任何不兼容问题，就根本无法挂载文件系统，但我真的担心我可能搞乱了文件系统。
任何帮助都将非常感激。
编辑：我使用 GParted 创建了 FS，同时了解到，与 mke2fs 不同，它默认为小于 16TiB 的驱动器（我的 8TB 驱动器就是这种情况）以 32 位模式创建文件系统。我通过检查 提供的文件系统功能验证了这一点tune2fs -l /dev/sda | grep features，否则将包含术语“64 位”。
答案1
有两个单独的兼容性检查；一个由内核执行，另一个由 e2fsprogs 实用程序执行。3.16 内核支持元数据校验和，因此挂载它没有问题。但是，Debian Jessie 中的 e2fsprogs 版本不支持。因此，尝试使用 e2fsck 检查文件系统失败，因为 e2fsprogs 的版本太旧了。我不确定哪个程序试图运行 e2fsck，但显然它忽略了 e2fsck 的退出状态，并且/或者可能是您手动挂载了它。
这就解释了为什么尽管 e2fsck 说无法检查文件系统，但您仍然能够挂载文件系统。
但另一个需要注意的是 3.16 是非常旧内核，虽然一些错误修复被反向移植，但并不是所有错误修复都被反向移植，而且 3.16 很久很久以前就停止了反向移植。而且，3.16 是在元数据校验推出后不久推出的，我当时无法全部保证 3.16.84 中不存在与元数据校验和相关的任何错误。但是，如果您只将一个文件复制到该文件系统，并且文件内容已检查出来，而 e2fsck 的现代版本未检测到任何问题，那么您可能就没问题了。