我在 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而無法運作。
於是我google了一下，發現元資料校驗和是在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 位元」。
答案1
有兩個單獨的兼容性檢查；一種是由核心執行，另一種是由 e2fsprogs 實用程式執行。 3.16核心支援元資料校驗和，因此安裝它沒有問題。然而，Debian Jessie 中的 e2fsprogs 版本卻沒有。因此，嘗試使用 e2fsck 檢查檔案系統失敗，因為 e2fsprogs 的版本太舊。我不確定哪個程式正在嘗試執行 e2fsck，但顯然它忽略了 e2fsck 的退出狀態，和/或可能您手動安裝了它。
這解釋了為什麼即使 e2fsck 說它無法檢查檔案系統，您也能夠掛載檔案系統。
另一個警告是 3.16 是非常舊內核，雖然一些錯誤修復被向後移植，但並非全部都是，並且 3.16 很久很久以前就停止了向後移植。而且，3.16 是元資料校驗和推出後不久，我不能全部保證 3.16.84 中不存在任何與元資料校驗和相關的錯誤。但是，如果您只將一個檔案複製到該檔案系統，並且檢查了該檔案的內容，而現代版本的 e2fsck 沒有偵測到任何問題，那麼您可能沒問題。