我在 64 位 ArchLinux（内核 5.4.50）上使用 e2fsprogs 1.45.6-2 对 HDD 进行 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 标志，它应该防止（非恶意）旧程序搞砸事情。
如果有任何不兼容问题，我预计根本无法挂载文件系统，但我真的担心我可能把 FS 搞砸了。
对此的任何帮助将不胜感激。
编辑：我使用 GParted 创建 FS，同时了解到，与 mke2fs 不同，它默认为 <16TiB 的驱动器创建 32 位模式的文件系统，我的 8TB 驱动器就是这种情况。我通过检查 提供的文件系统功能验证了这一点，tune2fs -l /dev/sda | grep features否则将包括术语“64 位”。
有两个单独的兼容性检查；一个是内核，另一个是 e2fsprogs 实用程序。3.16 内核支持元数据校验和，所以安装它没有问题。但是，Debian Jessie 中的 e2fsprogs 版本没有。因此，使用 e2fsck 检查文件系统的尝试失败了，因为 e2fsprogs 的版本太旧了。我不确定哪个程序正在尝试运行 e2fsck，但显然它忽略了 e2fsck 的退出状态，和/或您手动安装它。
这就解释了为什么即使 e2fsck 说它无法检查文件系统，您也能够挂载文件系统。
另一个警告是 3.16 是一个非常旧的内核，虽然一些错误修复是向后移植的，但并非所有修复都是如此，而且 3.16 很久很久以前就停止了向后移植。而且，在元数据校验和推出后不久，3.16 就发布了，我完全不能保证在 3.16.84 中没有任何与元数据校验和相关的错误。但是，如果您只将单个文件复制到该文件系统，并且文件的内容已检出，并且 e2fsck 的现代版本没有检测到任何问题，那么您可能没问题。