64 ビット ArchLinux (カーネル 5.4.50) 上で e2fsprogs 1.45.6-2 を使用して HDD を EXT4 フォーマットし、データでいっぱいにしました。その後、e2fsprogs 1.42.12-2+deb8u2 を使用して 32 ビット Debian Jessie (カーネル 3.16.84-1) を実行している別のコンピューターにインストールし、1 つのファイルをコピーしました。
このバージョンの違いは問題があり、ファイルシステムに損傷を与えた可能性がありますか?
32 ビット Jessie システムのシャットダウン中に、e2fsck エラー メッセージが表示されました。これは基本的に、metadata_csum が原因で実行できないことを示しています。
そこでグーグルで検索してみたところ、メタデータ チェックサムは 1.43 で導入されたことがわかりました。 https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums
私が本当に不快に感じるのは、次の引用文です... 古いファイルシステムのコードでは、メタデータ チェックサムが有効になっているファイルシステムに書き込むことはできません。metadata_csum フラグは ROCOMPAT フラグとして実装されており、(悪意のない) 古いプログラムが混乱を起こさないようにするはずです。
互換性の問題があればファイルシステムをマウントできなくなると予想していましたが、FS を台無しにしてしまったのではないかと本当に心配しています。
これに関してご助力いただければ幸いです。
編集: 私は FS を作成するために GParted を使用しましたが、その間に、mke2fs とは異なり、<16TiB のドライブに対してデフォルトで 32 ビット モードでファイルシステムを作成することを知りました。これは、私の 8TB ドライブの場合に当てはまります。 によって提供されるファイルシステム機能をチェックすることでこれを検証しましたtune2fs -l /dev/sda | grep features。そうでない場合は、「64 ビット」という用語が含まれます。
答え1
互換性チェックは 2 つあります。1 つはカーネルによるもので、もう 1 つは e2fsprogs ユーティリティによるものです。3.16 カーネルはメタデータ チェックサムをサポートしているため、マウントに問題はありませんでした。ただし、Debian Jessie の e2fsprogs のバージョンはサポートしていませんでした。そのため、e2fsck を使用してファイル システムをチェックしようとしましたが、e2fsprogs のバージョンが古すぎたため失敗しました。どのプログラムが e2fsck を実行しようとしていたのかはわかりませんが、どうやら e2fsck の終了ステータスを無視したか、手動でマウントした可能性があります。
したがって、e2fsck でファイル システムをチェックできないと表示されたにもかかわらず、ファイル システムをマウントできた理由が説明されます。
しかし、もう一つの注意点は、3.16はとても古いカーネルで、バグ修正の一部はバックポートされていますが、すべてではありません。3.16は、かなり前からバックポートされなくなっています。また、3.16はメタデータチェックサムが導入されて間もなくのことでした。全て3.16.84 では、メタデータ チェックサムに関連するバグがないことを保証します。ただし、そのファイル システムに 1 つのファイルのみをコピーし、ファイルの内容がチェックアウトされ、最新バージョンの e2fsck で問題が検出されない場合は、おそらく問題ありません。