要約:E2fsckは、-n
オプションではエラーを検出しませんでしたが、-p
(preen)でエラーを検出しました。エラーは修正されましたが、エラーメッセージは表示されませんでした。エラーは終了コードを介してのみ反映されます。これをどのように解釈しますか?
Ext2ファイルシステムを備えたUSBハードドライブを使用して、複数のマシンのバックアップを保存しています。最近、そのドライブで大量のデータスループットが発生したため、追加のファイルシステムチェックを行うことにしました。合計で、異なるオプションを使用して4回のe2fsck
実行を行いました。これは、私が(rootとして)使用したコマンドとその出力であり、e2fsck
の終了ステータスも含まれています。残念ながら、一部のフレーズはドイツ語にローカライズされていますが、(おそらく)重要なフレーズは英語です。
1回目の実行、読み取り専用:
# e2fsck -nv /dev/sdb1; echo $?
e2fsck 1.41.1 (01-Sep-2008)
WD-Elements: sauber, 709312/61046784 Dateien, 96258851/244182016 Blöcke
0
2回目の実行、読み取り専用強制:
# e2fsck -nfv /dev/sdb1; echo $?
e2fsck 1.41.1 (01-Sep-2008)
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung
709312 inodes used (1.16%)
95492 non-contiguous inodes (13.5%)
# von Inodes mit ind/dind/tind Blöcken: 109958/2429/7
96258851 blocks used (39.42%)
0 bad blocks
8 large files
564029 regular files
121351 directories
0 character device files
0 block device files
11 fifos
506224 links
23073 symbolic links (19397 fast symbolic links)
839 sockets
--------
1215527 files
0
3回目の実行、修復:
# e2fsck -pv /dev/sdb1; echo $?
WD-Elements: sauber, 709312/61046784 Dateien, 96258851/244182016 Blöcke
0
4回目の実行、強制的な修復:
# e2fsck -pfv /dev/sdb1; echo $?
709312 inodes used (1.16%)
95492 non-contiguous inodes (13.5%)
# von Inodes mit ind/dind/tind Blöcken: 109958/2429/7
96258853 blocks used (39.42%)
0 bad blocks
8 large files
564029 regular files
121351 directories
0 character device files
0 block device files
11 fifos
506224 links
23073 symbolic links (19397 fast symbolic links)
839 sockets
--------
1215527 files
1
コマンドは、間に何も触れずに次々に直接発行されました。
違いに注意してください:
最初の2回の実行では、ファイルシステムは読み取り専用で開かれ(-n
オプション)、最後の2回は実行の修復でした(-p
オプション)。
1回目と3回目の実行は強制されず、2回目と最後の実行は(-f
)でした。
1つの例外を除いて、すべての実行でファイルシステムデータの一致が報告されました。最後の実行(-pfv
)では、異なる数の「使用されたブロック」が報告されました。
最後の実行を除くすべてがステータス0で終了し、最後の実行(-pfv
)はステータス1で終了しました。
明らかに、最後の強制修復実行(-pfv
)は、他の実行では検出できなかったファイルシステムエラーを検出(および修正)しました。残念ながら、出力にそのエラーについてのヒントはありません。
今私の質問のために:
そこでどのようなエラーが見つかり、修正されましたか?使用済みブロックの数が間違っているのと同じくらい簡単でしたか?
そのエラーの原因は何でしょうか?ファイルシステムは常にきれいにアンマウントされていました。
ファイルシステムエラーは最終的にe2fsck
によって修正されました。しかし、そこに保存されているデータを信頼できますか?そもそもそのファイルシステムエラーの原因が何であれ、ディスク上のデータも破損したのではないでしょうか。これにより、ディスク上のすべてのデータが無価値になります。それともこれは妄想的ですか?どうして?
最後の質問は、ファイルシステムとデータを区別します。この点で、 Mikelの答え から " ジャーナリングファイルシステムは停電後の破損を保証しますか? "は関連性が高いです。残念ながら、ジャーナリングファイルシステムに焦点を合わせているため、Ext2には適用されません。
また Gillesの答え to " fsckによって行われたファイルシステム修正をテストする方法 "は良い読み物です:それによると、fsck
は一貫した状態を保証するだけですファイルシステムの、必ずしも最新のものではありません。
彼の コメント で、Luciano Andress Martiniは、e2fsck
の観察された、明らかに不可解な動作は、実行中のマシンのRAMエラーによって引き起こされた可能性があると指摘しました。同等の状況での関連する側面、ここでは当てはまらないようです:RAM with "memtest86 +"を一晩チェックし、エラーなしで16パスを完了しました。さらに、e2fsck -nfv
、e2fsck -pfv
、 e2fsck -fv
は、別のマシン(異なるハードウェア、カーネル、およびe2fsck
のバージョン)を使用してテスト対象のドライブで実行されます。これらはファイルシステムエラーを検出せず、上記の最後のe2fsck
コマンドによって報告されたファイルシステムデータ、特に番号を確認しました。また、無理なチェックで報告されたブロックの総数(244182016)も確認されました。
telcoMの回答 は、e2fsck
の観察された動作は、非常に古いファイルシステムを処理するときにe2fsck
が行うファイルシステム機能設定の変更で説明される可能性があることを示唆しています。残念ながら、この非常に一貫性のある説明はここには当てはまりません。ファイルシステムは、実際には、機能mke2fs
、ext_attr
、resize_inode
、filetype
、dir_index
、sparse_super
を有効にする新しいバージョンのlarge_file
(1.42.8)で作成されました。これは、上記のe2fsck
の実行によって変更されませんでした。
一方、USBドライブは非破壊読み取り/書き込み不良ブロックテストに合格し(3日かかりました。はい:指定されたブロックサイズ(-b
)とブロック数(-c
)が重要です)、いくつかのオフラインS.M.A.R.T.テスト。
このファイルシステムは非常に古いマシンで使用されているとおっしゃいました。ファイルシステムが元々、ファイルシステムのオンライン拡張用にメタデータスペースを予約するためのmke2fs
ファイルシステム機能をサポートしていない非常に古いresize_inode
ツールで作成された場合、2回目の実行が可能になる可能性があります。 e2fsck
バージョン1.14.1では、自動的に追加されました。
私が正しく思い出せば、割り当てはそれを理解していない古いシステムにとっては完全に無害ですが、ファイルシステムが拡張された場合でも、重要なメタデータ構造を大幅に再編成することなく拡張できます。
これを確認するには、USBドライブのファイルシステムと古いマシンのext2ファイルシステムの1つでtune2fs -l
を実行し、結果を比較します。ファイルシステムがマウントされている場合でも、それを行うことができます。 USBドライブの出力のresize_inode
行にキーワードFilesystem features:
が含まれていて、古いマシンのローカルext2ファイルシステムにそのキーワードがない場合、最も可能性の高い説明はe2fsck -pfv
は、将来のダウンタイムを回避するのに役立つことを期待して、その小さな割り当てを行う機会を得ました。