突然の大規模なファイルシステムの損傷の原因?(「ルートiノードはディレクトリではありません」)[終了]


8

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エラーは表示されず、カーネルログも表示されません。badblocksswap lv全体で書き込みモードを実行しても問題は検出されません。したがって、ディスクに障害が発生している可能性がありますが、明白な方法ではありません。

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

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

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

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

回答:


4

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

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

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


ああ、それであなたはスーパーブロックが壊れていたので、iノード領域へのポインタは実際にはiノードをまったく指さなかったと思うので、それらはすべて壊れて見えましたか?それは理にかなっている。
poolie

他のスーパーブロックで確認しても役に立たなかった。
poolie

2

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


このSSDでそれを2回見ましたが、磁気ディスクを備えた同じシステムや、別のSSDを備えた別のシステムではまったく見ていません。したがって、この時点でSSDを疑っています。
poolie

1

更新:最終的に、問題はある種の複雑なSSDの障害であると確信しました。磁気ディスクに交換しましたが、またトラブルはありませんでした。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.