lmo*_*oly 2 linux filesystems ext4
我在 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 标志，它应该防止（非恶意）旧程序搞砸事情。
我原以为如果存在任何不兼容问题，根本无法挂载文件系统，但我真的担心我可能会弄乱文件系统。
对此的任何帮助将不胜感激。
编辑：我使用 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 没有检测到任何问题，那么您可能没问题。