抽象的な:E2fsckはこのオプションをエラーなしで見つけまし-n
たが、-p
間違っています。エラーを修正しましたが、エラーメッセージは表示されませんでした。エラーは終了コードによってのみ反映されます。これをどのように説明しますか?
私はExt2ファイルシステムを備えたUSBハードドライブを使用して複数のシステムのバックアップを保存します。最近、このドライブで膨大なデータスループットが発生したため、追加のファイルシステムチェックを実行することにしました。全体として、私はe2fsck
さまざまなオプションを使用して4回の実行を実行しました。以下は、rootとして使用したコマンドとその出力ですe2fsck
。残念ながら、一部のフレーズはドイツ語でローカライズされていますが(おそらく)重要なフレーズは英語です。
初回実行、読み取り専用:
# 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
これらのコマンドは、間に他のものに触れることなく、1つずつ直接実行されます。
違いを参照してください:
最初の2つの実行ではファイルシステムが読み取り専用で開き(
-n
オプション)、最後の2つの実行ではクリーンアップでした(-p
オプション)。1次と3次は必須ではなく、2次と最終車は(
-f
)です。1つの例外を除いて、すべての実行で一貫したファイルシステムデータが報告されました。最後の実行(
-pfv
)では、「使用されたブロック」の数が異なるように報告されました。最後の実行を除くすべての実行は状態0で終了し、
-pfv
これは状態1()で終了します。
明らかに、最後の強制デフラグ実行(-pfv
)では、他の実行で見つからないファイルシステムエラーを検出して修正しました。残念ながら、出力エラーのためのヒントは提供されません。
今私の質問に答えてみましょう。
そこでどのようなエラーが検出され修正されましたか?使用されたブロックを誤って計算するのと同じくらい簡単ですか?
このエラーの原因は何ですか?ファイルシステムは常にきれいにアンマウントされます。
ファイルシステムエラーは最終的に修正されました
e2fsck
。しかし、その中に保存されたデータを信じることができますか?最初にファイルシステムエラーを引き起こした原因がディスク上のデータも破損していましたか?これにより、ディスク上のすべてのデータが無駄になります。それとも妄想ですか?なぜ?
最後の質問はファイルシステムとデータを区別します。これに関して、ミケルの答え到着する」停電後もログファイルシステムが破損しないことを保証できますか?「関連性は非常に高いですが、ジャーナリングファイルシステムに焦点を当てているため、Ext2では機能しません。
返品ザイルズの答え到着する」fsckで完了したファイルシステムの変更をテストする方法「よく読んでください。これにより、fsck
ファイルシステムは必ずしも最新の状態ではなく、一貫した状態のみが保証されます。
アップデート1
彼のコメントLuciano Andress Martiniは、観察された明らかに恥ずかしい動作がe2fsck
ランチャーのRAMエラーによって引き起こされる可能性があることを示唆しています。これは同様の状況で非常に関連性の高い側面ですが、ここには適用されないようです。一晩「memtest86+」でRAMを確認し、エラーなしで16回のパスを完了しました。また、別のコンピュータ(他のハードウェア、カーネル、バージョン)を使用してテストドライブでe2fsck -nfv
、、を実行しましたe2fsck -pfv
。これはファイルシステムエラーを示さず、上記の最後のコマンドで報告されたファイルシステムデータ、特に使用されているブロックの数を確認しました。さらに、非必須チェックで報告されたブロックの総数(244182016)も確認されました。e2fsck -fv
e2fsck
e2fsck
アップデート2
テレコムの答えe2fsck
観察された動作は、非常に古いファイルシステムを処理するときのファイルシステム機能設定の変更として説明できることが示唆されています。e2fsck
残念ながら、この非常に一貫した説明はここには適用されません。ファイルシステムは、実際に、、、、、mke2fs
機能が有効になっている最新バージョン(1.42.8)を使用して作成されました。上記の実行はこれを変更しませんでした。ext_attr
resize_inode
dir_index
filetype
sparse_super
large_file
e2fsck
アップデート3
一方、USBドライブは非破壊読み取りおよび書き込み不良ブロックテスト(3日かかりました。例:指定されたブロックサイズ(-b
)およびブロック数(-c
)が重要)と複数のオフラインSMARTテストに成功しました。
ベストアンサー1
私の質問に役立つ貢献を追加するために、私はいくつかの調査をしました。一部の結果は一般的な意味を持つ可能性があるため、この自己回答に要約します。
注:問題の定義によれば、以下のすべてはe2fsck
バージョン1.41.1を参照し、ジャーナルのないExt2ファイルシステムに焦点を当てています。ただし、これらの一般用語は、最新バージョンのプログラムやファイルシステムにもある程度適用されます。
教訓を得る
見出しから始めましょう。その理由は次のとおりです。
たとえば、次のようにC言語環境で実行します
e2fsck
。LC_ALL=C e2fsck ...
これにより、英語でメッセージを受け取ることができ、オンラインで特定のヘルプを見つけやすくなります。
この
-y
オプションは慎重に使用してください。e2fsck
表示されるすべてのプロンプトに自動的に「はい」と答えます。これらの質問には、常に「このエラーを修正してもよろしいですか?」などの質問が含まれているわけではなく、「影響を受けるファイルを削除してもよろしいですか?」という質問もあります。ファイルシステムをいくつか変更して
e2fsck
状態1(または3)で終了しても、ファイルシステムエラー(破損)があることを意味するわけではありません。e2fsck
ハンドルSIGINT
(Ctrl-C)しかし、私はそれに頼らないでしょう。 (個人的な考えです。)
次の点に焦点を当てます。情報あなたはe2fsck
:
e2fsck
ファイルシステムに含まれる可能性のあるエラーと、それを処理する方法を知りたい場合は、-p
(トリム)オプションを使用しないでください。対話的に(つまり、、、、
e2fsck
オプションなしで)実行すると、読み取り専用()または対照()の実行よりも見つかったエラーに関するより多くのメッセージが出力されます。のエイリアスです。 「はい」実行()を使用すると、基本的に対話的に実行するのと同じ情報を取得できます。-n
-p
-a
-y
-n
-p
-a
-p
-y
非常に似ていますが、このオプションは
-n
対話型の正確なテスト実行を生成しません。このオプションを使用しないと、自分で確認する
-f
必要があります。e2fsck
これにより、決定を推論するための追加情報が提供されます。例:... primary superblock features different from backup, check forced.
これを見逃したくない場合は、そのオプションを使用せずに起動し、ファイルシステムがきれいに見え、チェックが拒否された
-f
場合は2回目の試みでのみ使用してください。e2fsck
e2fsck
全体像を見るには、終了コードを確認することを忘れないでくださいecho $?
。
小切手の種類
インタラクティブ:-n
オプションとを-p
使用しないと、-a
対話型ファイルシステムチェックが実行されます。つまり、あらゆる段階で何をしたいのか尋ねます。これにより、プロセスを最大限に制御できます。-y
e2fsck
警告:ファイルシステムのサイズと状態によっては、これがすぐに退屈になる可能性があります。 inodeの後にinodeを修正する必要があると想像してください。そのような会議は数時間続く可能性があり、それより悪化する可能性があります。
さらに、問題が自分に慣れていない方向に流れている場合、状況は本当に怖いかもしれません。
邪魔する:このように対話型チェックが不可能になると、e2fsck
ハンドル(Ctrl-C)を知ることがSIGINT
より良い可能性があります。
実際にはいくつかの魅力的なレポートがあります。マッドハッターでそしてクリス。しかし、すでに述べたように、私はそのような妨害を避けようとします。
理由は簡単です。ファイルシステムの検査は複雑なプロセスであり、破損修復は一貫した方法で行われるべきであり、中断処理ははるかに複雑です。複雑なソフトウェアと同様に、信号ハンドラにもバグがある可能性があります。例を見るこの投稿アンドレアス・ディルガーの地音。では、なぜリスクを負うのか?もちろん妥当な理由があるかもしれませんが、自分で判断してみてください。
読み取り専用:確認するファイルシステムの状態についてほとんどわからない場合は、e2fsck
この-n
オプションを最初に使用するのが最善です。以下に示すように、これは正確なテスト実行を生成しませんが、インタラクティブな実行で何が期待できるのかについて良い印象を与えます。
整える: e2fsck
-p
このオプションを使用すると、ファイルシステムのデフラグが実行されます。これマンページ e2fsck(8)有望なようです。
このオプションを使用すると、e2fsckは手動介入なしに安全に回復できるすべてのファイルシステムの問題を自動的に回復します。
ただし、これは一部のファイルシステムエラーのみを修正することを意味します。ソースが示すように、安全に処理できないエラーが検出されたe2fsck
場合-p
、実行は停止し、残りのタスクは単にクリーンアップするのではなく、後続の実行のために残されます。
また、上記のように、-p
エラーと修正に関する情報は少なくなります。
例:e2fsck
オプションで開始すると、-y
対話型実行と同じ結果が生成され、対話型実行に関するすべての質問に「はい」と答えます。このアプローチの欠点はすでに上で述べた。
期待される:私が知る限りこのセクションのの"Ext2fsディレクトリ構造の取り消しミニHOWTO「このプログラムを使用すると、e2fsckの質問に詳細なレベルで自動的に答えることができます。予想される。そこからe2fsck
次のラッパースクリプトを使用します。
#!/usr/bin/expect -f
set timeout -1
spawn /sbin/e2fsck -f $argv
expect {
"Clear<y>? " { send "n" ; exp_continue }
"<y>? " { send "y" ; exp_continue }
}
それでは「Clear?」プロンプト(「n」を使用)を使用するすべての質問と、「y」を使用する他のすべての質問に自動的に答えます。詳細については、Expectのドキュメントを参照してください。バラよりこの問題By Wrothgarr これはExpect forを使用する別の例ですe2fsck
。
明らかに、私はこのスクリプトを盲目的に使用することをお勧めしません。ここでは「教育目的」としてのみ引用されています。
このアイデアを取り、自分のニーズに合わせてカスタマイズしたい人のために、e2fsck
ソースファイルe2fsck /problem.cの先頭に近いprompt
この配列は、合計20の使用されe2fsck
たヒントを保持するように定義されています。その一部は内部でのみ使用されます。プロンプトとファイルシステムエラーの相互関係については、後で詳しく説明します。
ソースから学んだ。
会話:ファイルシステムで見つかったエラーのほとんどは、e2fsck
e2fsck/problem.cファイルで定義されている関数を参照してください。fix_problem
この機能は、指定されたオプションに従って各エラーに対してユーザーと適切な会話を実行しますe2fsck
。
これを行うには、同じファイルe2fsck / problem.cで以前に定義されたfix_problem
配列で現在のエラーコードを見つけます。problem_table
この配列は、各エラーコードにエラーメッセージテンプレート、ユーザーに尋ねるプロンプト、エラー処理の詳細を制御するビットマスクを提供します。 (一部のエラーでは、「コードを隠す」という追加のエラーコードも参照されます。このコードのダイアログボックスは後で実行されますが、これは私たちにとって重要ではありません。)
私たちの問題にとって重要な2つのフラグは、このビットマスクで時々使用されPR_PREEN_NOMSG
ますPR_NO_NOMSG
。設定すると、それぞれ-p
実行エラーメッセージと実行エラーメッセージは表示されません-n
。これにより、エラーを定義し、-y
対話型実行または実行に関する詳細情報を取得できます。
の定義はproblem_table
292個のエラーコードを指定し、そのうち23個はフラグが付けPR_PREEN_NOMSG
られ、1個のみフラグが付けられますPR_NO_NOMSG
。それらのどれもとPR_PREEN_NOMSG
記号の両方を持っていませんPR_NO_NOMSG
。
もう一つの興味深いフラグPR_PREEN_OK
:このフラグのエラーはpreen(run)によって安全に処理される可能性があります-p
。 preenは他のエラーも処理できます。下記の「特殊事例」をご覧ください。しかし、これらのエラーはほとんどです。配列の82個のエラーがproblem_table
表示されましたPR_PREEN_OK
。
スタート:Linuxバージョン1.41.1では、e2fsck / unix.cファイルの関数としてe2fsck
実行が開始されます。main
パス0:ログを初期化して確認した後(この質問には関係ありません)、ファイルシステムに対していくつかの基本的な確認とクリーンアップが行われます。これをパス0ともいいます。主な部分はcheck_super_block
ソースファイルe2fsck/super.cの関数で完成します。
名前にもかかわらず、この関数はスーパーブロックを担当するだけでなく、ブロックグループ記述子も確認します。これにより、各ブロックグループの空きブロックと空きinodeの数を合計し、その結果をスーパーブロックのグローバル値と比較します。
e2fsck
これらの値が一貫していない場合はどうなりますか?コマンドラインオプションによって異なります。-n
ファイルシステムは実行に有効ではないと見なされ、後で完全なチェックが強制されます。他のすべての場合(、インタラクティブ実行)では、完全な-p
確認-y
を強制することなく、スーパーブロックの総数が自動的に更新されます。実際に後者が実行されて他のエラーが見つからない場合、これらの自動修正にもかかわらずファイルシステムはクリーンであると報告されます。
この関数はcheck_super_block
また、inodeのサイズ変更の確認、分離されたinodeのクリーンアップ、ログ管理などのタスクも実行しますが、これは私たちの問題では重要ではないようです。
飛び越える:オプションがまだファイルシステム全体のスキャンを強制していない-f
場合は、ファイルシステム全体のスキャンe2fsck
を直接実行することにしました。既知の基準は、最後の確認以降のインストール数、完全に削除されない、既知のファイルエラーなどです。
ただし、このオプションが使用されていない場合にのみ他の基準も適用されます-n
。つまり、次の数量のスーパーブロックとバックアップの違いです。
large_file
,dir_nlink
, をextent
除くファイルシステム機能の有効化総ブロック数、
索引ノードの総数、
ファイルシステムUUID。
標準から特定のファイルシステム機能を除外する理由は、カーネルが必要に応じてこれらの機能を動的に設定し、バックアップではなくスーパーブロックでのみこれを実行できるためです。例外的な機能の場合、これらの違いは完全な検査を保証するのに十分重要ではありません。対照的に、このext_attr
機能はカーネルによって動的に設定される可能性がありますが、この場合はバックアップの更新が重要であるため、この機能も例外ではありません。
自分でチェック全体を強制することを決定すると、e2fsck
不快感を説明するメッセージが印刷されます。これがスーパーブロックとそのバックアップの間の指定された違いの1つが原因で発生した場合は、次のメッセージが表示されます。
... primary superblock features different from backup, check forced.
メッセージにおいて、「機能」という用語は、純粋に「ファイルシステム機能」よりも広い意味を有する。たとえば、総ブロック数も含まれます。また、見ることができますこの投稿著者: エリック・サンディン(Eric Sandin)これこれに関連して、Theodore Tso。
-n
それにもかかわらず、上記のように、この場合スーパーブロックのバックアップは考慮されないため、このメッセージはすぐには表示されません。
フルスキャンが実行されない場合、by-f
またはbyに関係なくチェックe2fsck
(e2fsck
辞書)はスキップされます。この場合、e2fsck
ファイルシステムは状態0の完全な終了として報告されます。パス0でいくつかの修正が行われた場合も同様です(例えば、スーパーブロックの総空きブロック数の修正)。
パス1〜6:フルスキャンでは、e2fsck
それぞれが異なる焦点を置き、ファイルシステムに対して少なくとも5回のフルスキャンが実行されます。これは、ソースファイルe2fsck/pass1.cからe2fsck/pass5.cにそれぞれ定義されている関数によって実行されますe2fsck_pass1
。e2fsck_pass5
特別なファイルシステムの破損を処理する必要がある場合は、チャンネル1を補完する追加のチャンネルがある可能性があります。これはpass 1Bからpass 1Dにラベル付けされており、その機能はe2fsck / pass1b.cで定義されていますpass1b
。pass1d
ディレクトリ災害時はパス3の一部であり、e2fsck/rehash.cファイルの関数によって実行され、e2fsck_rehash_directories
パス3Aと見なされます。
またPR_6_RECREATE_JOURNAL
、ログを再生成する必要がある場合は、エラーコードが使用されます。明らかに、これは別々のパス(パス6)を構成すると見なされます。関数で実行されますmain
。
problem_table
配列で定義されたエラーのほとんどは、これらの手順で確認されます。各エラーに対して発生したパス数は、エラーコード名で確認できます。数字はコード名の最初の下線の後にあります。たとえば、エラーはPR_1_TOO_MANY_BAD_BLOCKS
パス 1 で処理され、PR_3A_OPTIMIZE_DIR_ERR
パス 3A で処理されます。
この質問で特に興味深いのは、パス 5 の開始時に使用可能なブロックと使用可能な inode の合計数が再確認されることです。パス 0 のクイックチェックとは異なり、ブロックグループ記述子ではその値のみがチェックされます。まとめると、今回はe2fsck
ファイルシステムプロセス全体で徹底的に収集されたデータに基づいて数を計算します。これは、e2fsck/pass5.cファイルで定義された関数によってcheck_block_bitmaps
行われます。check_inode_bitmaps
スーパーブロックの値と比較した結果の値の差は、誤差のPR_5_FREE_BLOCK_COUNT
合計と見なされますPR_5_FREE_INODE_COUNT
。ただし、これらのエラーはフラグが立てられ、PR_PREEN_NOMSG
collate()中に明示的に報告されません-p
。
特別な場合:エラーディレクトリをe2fsck
呼び出すか参照しなくてもファイルシステムで実行できるいくつかの修正があります。これらの変更はオプションなしでのみ行われ、出力には通知されませんが、終了状態で行うことができます。ソースでそのうちの3つを見つけました。fix_problem
problem_table
-n
-n
0(なし)が渡されると、スーパーブロックの合計使用可能ブロックと使用可能なinodeの数が変更されます。これは上で議論された。パス1の間、スーパーブロック(なし
-n
)の最後の孤立フィールドが設定されると自動的にクリアされます。インデックスディレクトリのinodeに格納されているリンク数の値が以前に上限を超えたことを示し、現在の実際の数がこの制限を下回っている場合、inodeの値は手順4で自動的に変更されます(別途作業を実行する必要はありません)。だから
-n
)。
終了ステータス:完全(強制)検査の場合、終了コードは、main
検査の完了後の後者の結果の分析中に関数によって決定されます。チェックが途中でキャンセルされていない場合、これまでの終了ステータスは0になります。 、ファイルシステムに変更はありません。
最後の連絡:チェックが途中でキャンセルされない場合、この関数はmain
スーパーブロックのマウント数をリセットし、タイムスタンプを更新して、e2fsck
今後の実行で次のチェック全体を強制する必要がある時期を知ることができます。これは終了ステータスが決定された後にクリーンアッププロセス中に実行されるため、この変更はステータスに影響しません。
信号ハンドラ:PRS
main
e2fsck/unix.c で定義された呼び出された関数ではe2fsck
、 、 と のシグナルハンドラが生成されます。後者の2つは、後述のように進行情報を切り替えるために使用できます。SIGINT
SIGTERM
SIGUSR1
SIGUSR2
マンページ e2fsck(8)。
明らかに、電子は安全な中断と終了を可能にするように処理されますe2fsck
。
テストを通して学ぶ
質問に示されている動作を再現するためにe2fsck
テストExt2ファイルシステムを設定し、容量の最大10%までダミーファイルで埋め、16進エディタを使用していくつかの人的エラーを導入しました。次に、質問と同じコマンドを使用して適切なファイルシステムを確認して、出力と終了ステータスを比較しますe2fsck
。
問題を最後に実行したときに使用されたブロックの数が変更されました。e2fsck
この値は、使用可能なブロック数と総ブロック数に基づいて明確に計算されます。そのため、この数量をヒューマンエラーの対象として選択しました。
スーパーブロックの空きブロック数:スーパーブロックのデータ構造は次のとおりです。このファイル。 (Ext4ファイルシステムを説明するこのドキュメントの最新バージョンは、以下にあります。)こここれに基づいて、Hex Editorを使用してスーパーブロックの空きブロック数を2つ減らしました。
この人的エラーはe2fsck -nv
(なしで-f
)検出され、大声で文句を言い、全体の確認を強制し、終了ステータス4で終了します。
また、読み取り専用実行(-nfv
)を強制するとエラーが報告され、状態4で終了します。
後続の-pv
実行(しない-f
)では、ファイルシステムがクリーンであることが確認され、エラーに関する通知は提供されませんでした。ただし、エラーを修正し、修正された値に基づいて使用されたブロック数を出力しますが、状態0で終了します。
同じエラーが再び発生した後、強制クリーンアップ実行(-pfv
)もエラーを報告せずに代わりにエラーを修正し、状態1で終了しました。
e2fsck
この動作は、上記のソースから知られている内容からよく理解できます。
これは、質問で説明されている検査結果を引き起こす他のエラーでなければならないことを意味します。それ以外の場合は、読み取り専用の実行によって報告され、最初の(非強制)最適化によって変更され、最後の実行でクリーンなファイルを見つけることができます。ファイルシステム
スーパーブロックの総ブロック数:Hex Editorを使用して、スーパーブロックの総ブロック数を2つ減らしました。
-nv
-f
これは、ファイルシステムをクリーンであると報告し、ステータス0で終了する(without)を実行しても検出されません。
このチェック(-nfv
)を強制的に実行すると、いくつかのエラーが見つかりました。つまり、e2fsck
操作されたブロックの総数を真剣に考えましたが、最後のブロックグループとスーパーブロックの利用可能なブロック数が間違っていることがわかりました。また、ブロックビットマップの末尾のパディングが設定されていないことが確認されました。終了状態は 4 です。
スーパーブロックとそのバックアップの違いにより、後続のデフレ(-pv
、なし)は完全なチェックを強制します。-f
このプロセスでは、読み取り専用の実行を強制して、以前に検出されたすべての「誤った」エラーを修正しました。ただし、使用可能なブロック数に関する通知は提供せず、ビットマップの塗りつぶしの(「不良」)エラーのみを報告します。最後に状態1で終了する。
同じバグを再導入するforce-collation(-pfv
)は基本的に同じことを行いますが、スーパーブロックとそのバックアップ(以前は強制チェックの理由で提供されていた)との違いを知らない点だけが異なります。
この動作は、e2fsck
上記のソースの議論でも理解できます。ただし、これは質問に記載されているものとは異なります。それでは別のバグがあるのは間違いありません。
バックアップの空きブロック数:スーパーブロックバックアップのブロック番号は、以下で確認できます。
LC_ALL=C dumpe2fs <device> | grep -i superblock
ただし、最初のスーパーブロックバックアップの空きブロック数は完全に無視されますe2fsck
。実際に本当にクリーンなファイルシステムでもメインスーパーブロックにある値と値が異なるようです。実際に考えてみると、すべてのバックアップでこの値を継続的に同期させることは非常にオーバーヘッドになります。だからまったく意味がないと思います。
バックアップの総ブロック数:また、Hex Editorを使用して最初のスーパーブロックバックアップの総ブロック数を2つ減らしました。
e2fsck
-nv
読み取り専用モードでは、この人の間違いは完全に無視されます-nfv
。
クリーンラン(-pv
、なし-f
)はフルスキャンを強制し、次のメッセージを表示します。
... primary superblock features different from backup, check forced.
この処理中にエラーを修正し、関連するメッセージがなくなり、状態1で終了します。
同じエラーが再び発生した後、forcecollation(-pfv
)は同じことをしましたが、エラーメッセージは表示されませんでした。
繰り返しますが、この動作は上記のソースの議論でよく理解されています。これは質問で観察されるものとは異なります。
さらに、e2fsck
質問で説明されている強制実行されていない実行と、アップデート1で説明されてから実行されたチェックは、同じ合計ブロック数を報告します。したがって、値は1回の実行で変更されないため、目的のエラーの対象になる可能性はありません。
これが質問に対する答えにつながりますか?
簡単に言うと:いいえ。
質問に記載されている個々の実行ごとに観察された動作を引き起こす可能性があるバグが見つかりましたe2fsck
。しかし、シーケンスのすべての実行に対して動作を引き起こすバグが見つかりませんでした。
のすべてのエラーは、実行、実行、またはその両方によって報告される可能性がproblem_table
あるため除外されます。-nfv
-pfv
上記の「特殊ケース」を考慮して、読み取り専用実行では、使用可能なブロックまたは使用可能なinodeの数が誤って報告されます。そうではありません。
他の「特別な場合」のために使用されたブロックの数は、最後の実行で観察されたものと変わりません。
しかしe2fsck
、最終的には複雑なソフトウェアなので、何か見落とした可能性があります。
結果
これらの結果に直面して、次のワークフローを使用すると、インタラクティブな部分で不快な驚きを避けますe2fsck
。
これはハードウェアが正常であると仮定します!特に、この点でドライブを信頼できない場合は、無条件の手順3(ファイルシステムのバックアップ)から始めて、説明した順序で残りの手順を続行してください。
走ってみてください
-nv
:LC_ALL=C e2fsck -nv <device>; echo $?
ファイルシステムがクリーンであると報告されている完全なスキャンをスキップした場合は、強制
e2fsck
的に手順1を繰り返すようにするスキャンを使用してください-f
。見つかった破損に応じてバックアップファイルシステムを使用してください
dd
。これにより、次の手順で問題が発生した場合に現在の状態を復元できます。読み取り専用の実行結果に基づいて可能であるように見える場合は、次のコマンドを使用して対話形式で確認してください。
LC_ALL=C e2fsck -v <device>; echo $?
-f
完全な検査を受けるには、必要に応じて強制してください。インタラクティブランニングが不可能な場合、どうすればよいかは、これまでに発見された内容によって異なります。
付録:ファイルシステム機能の確認
2fs ダンプ:このプログラムをdumpe2fs
使用すると、ファイルシステムでどの機能が有効になっているかを確認できます。
これは未知の機能にも当てはまります。この場合、dumpe2fs
スーパーブロックの機能フィールドでそのビットを一意に識別する共通の機能名が使用されます。たとえば、これはFEATURE_R16
スーパーブロックの読み取り専用互換機能フィールドのビット16(0から計算)に対応します。同様に、FEATURE_I31
互換性のない機能フィールドの最上位ビットに対応する。
compression
この機能が設定されている場合は、dumpe2fs
この-f
オプションで開始する必要があります。
ただし、プログラムバージョン1.41.1は、64bit
有効化および無効化された機能(有効化および無効化など)の特定の組み合わせで浮動小数点例外が原因で競合が発生するため、少しバグがあるようですjournal_dev
。
デバッグ:有効なファイルシステム機能の場合、コマンドは同様の出力をshow_super_stats
生成します。このプログラムは、未知の機能についても教えてくれます。debugfs
dumpe2fs
また、プログラムバージョン1.41.1には一種のバグがあるようです。show_super_stats
または、有効にすると、コマンドは分割エラーのためにクラッシュします。同様に、機能が無効の状態で有効になると、プログラム全体が浮動小数点例外によってクラッシュします。compression
journal_dev
dumpe2fs
debugfs
64bit
journal_dev
2fs調整:既知のファイルシステム機能のみが有効になっている場合は表示できますtune2fs -l
。ただし、不明なファイルシステム機能が有効になっている場合、-f
このオプションを使用してもプログラムの起動は拒否されます。