状況は次のとおりです。私は（非常に古い）ファイルシステムを持っています。これは2006年に作成されました。 ext2で始まり、ext3、ext4、64ビットext4に移動しました。私は最近Metadata_csumを有効にしましたが、問題はありませんでした。サンプリングすると、最も古いデータも正しく取得されるようです。ファイルシステムの fsck ルーチンは作成後に無効になりました。 HBAケーブルホッピングのため、基本的なmdraidにわずかなOOPSが発生した後にFSを再組み立て、現在インストールする前にfsckingしています。 1つの潜在的な問題は、mdraidの再構成にわずかに多くのOOPSがあり、ボリュームに（正しい以前の）メタデータ0.90に再割り当てされる前にメタデータ1.2が割り当てられたことです。その結果、各基本パーティションの先頭から約300〜4096バイトが上書きされます。ディスクごとに1つと仮定すると、合計12個のブロックです。これを念頭に置いてfsckingを行います。もちろん、最初のスーパーブロックは破損していますが、fsckはバックアップスーパーブロックに正しく移動して幸せに削除されます。バグがものすごく多いことを除いては特にバグはないようですInode nnnnn passes checks, but checksum does not match inode. Fix? no。非常に大きな数字とは、2.6*10^9 inode を持つファイルシステムでほぼ 10^6 を意味します。唯一の他のエラーが20個未満であることを考えると、「Inode nnnn contains garbage. Clear? no古い」iノードのメタデータ（つまり、機能が有効になってから記録されていないメタデータ）が単に間違っている可能性がありますか？ 2010年から2013年まで、これについて多くの議論があったが消えた。この場合の最良の方法は、その機能を削除し、他のバグを修正して再度追加することですか？ 40TBのボリュームなのに何の理由(TM) 最後のバックアップから約18ヶ月が経過しました。
参考までに、システムは現在最新のアップデートを含むDebian 11 amd64を実行しています。