web-dev-qa-db-ja.com

突然の大規模なファイルシステムの損傷の原因？ （「ルートiノードはディレクトリではありません」）

Patriot Torx SSDを搭載したMaverickを実行しているラップトップを（昨日まで非常に喜んで）持っています。パーティション全体のLUKS暗号化。その上に1つのLVM物理ボリューム。次に、その上にあるext4論理ボリュームのホームとルート。

昨日起動しようとしたところ、ルートファイルシステムをマウントできないと文句を言った。 fsckを実行すると、基本的にすべてのiノードが間違っているようです。ホームとルートの両方のファイルシステムで同様の問題が発生します。バックアップスーパーブロックを確認しても効果はありません。

e2fsck 1.41.12 (17-May-2010)
lithe_root was not cleanly unmounted, check forced.
Resize inode not valid.  Recreate? no

Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory.  Clear? no   
Root inode has dtime set (probably due to old mke2fs).  Fix? no
Inode 2 is in use, but has dtime set.  Fix? no
Inode 2 has a extra size (4730) which is invalid
Fix? no
Inode 2 has compression flag set on filesystem without compression support.  Clear? no
Inode 2 has INDEX_FL flag set but is not a directory.
Clear HTree index? no
HTREE directory inode 2 has an invalid root node.
Clear HTree index? no
Inode 2, i_size is 9581392125871137995, should be 0.  Fix? no
Inode 2, i_blocks is 40456527802719, should be 0.  Fix? no
Reserved inode 3 (<The ACL index inode>) has invalid mode.  Clear? no
Inode 3 has compression flag set on filesystem without compression support.  Clear? no
Inode 3 has INDEX_FL flag set but is not a directory.
Clear HTree index? no
....

ファイルシステム全体でstringsを実行すると、ファイル名とユーザーデータのようなものがそこにあることがわかります。万が一に備えて、再構築する前に暗号化されていないディスクのイメージを保存することもありますが、私は十分に優れたバックアップ（木目調）を持っているので、個々のファイルをプルバックするのに手間取ることはありません。

smartctlはエラーを表示せず、カーネルログも表示しません。 swap lv全体で書き込みモードbadblocksを実行しても、問題は見つかりません。したがって、ディスクに障害が発生している可能性がありますが、明白な方法ではありません。

この時点で、私は基本的に、彼らが言うようにfsckedですか？再インストールに戻って、おそらくディスク上で不良ブロックを実行してから、バックアップから復元しますか？意味のあるバグを報告するのに十分なデータもないようです...

このマシンを前回使用したときにクラッシュしたことを思い出しません。

この時点で、バグまたはメモリの破損が原因で、ディスクが最後に実行されたときにディスク全体にガベージが書き込まれたか、SSDのある種の微妙な障害モードが発生したと考えられます。

これを引き起こしたと思いますか？他に試してみたいことはありますか？

linuxssdcorruptionfsckext4
8
poolie

pdate：結局、問題はある種の複雑なSSDの故障であると確信しました、またはおそらくカーネルとSSD間の相互作用を推測しています。磁気ディスクに交換しましたが、二度とトラブルはありませんでした。

1
poolie

最初のスーパーブロックが壊れているようです。スーパーブロックはファイルシステムの最も重要な部分であるため、スーパーブロックのコピーは多数あります。 e2fsckオプションを使用して-bを試し、スーパーブロックの別のコピーに正しい情報があるかどうかを確認できます。 -bオプションの詳細、および追加のスーパーブロックの場所を特定する方法については、 e2fsck（8） を確認してください。

IIRC、ルートディレクトリのコピーは1つしかないので、破損している場合は、空にして再作成する必要があります。最初はルートディレクトリの下にあるディレクトリが/ lost + foundに表示され、そこから再配置する必要があります。

Iノードテーブルは、パーティション全体に分散されます。それらすべてを失うことはまずありません。回復可能なファイル。ファイルを元のディレクトリに再配置できない場合は、/ lost + foundで終わります。

4
Juliano

私はこれを見たことがあります。これはUbuntu 10.10と関係があります。バグトラッカーは何度か投稿されているので、見回してみます。確かに、ディスクのスナップショットを取り、それをワイプしてセカンダリシステムにドロップし、バグが繰り返されるかどうかを確認します（ディスクを除外するため-犯人ではない可能性があります）。

2
Publiccert