4つのEXT4ファイルシステムをホストする1つのハードドライブ、名前をA（1,2,3,4）とします。各ファイルシステムはfstabにエントリをインポートしますが、ほとんどマウントされず、ドライブが初期化されません。 udiskctlを介して電源を切ります。
8つのEXT4ファイルシステムをホストする1つのハードドライブ、各ファイルシステムは私のfstabにエントリをインポートします。そのうちの4つはB（1,2,3,4）が初期化時に自動的にマウントされると仮定し、残りの4つはC（1,2, 3,4）必要に応じて頻繁にインストールされます。
このような場合（A（1,2,3,4）はマウントされず、関連するドライブはダウンし、C（1,2,3,4）ファイルシステムはマウントされていません）、何らかの理由で（停電、カーネルパニック、ハード）リセット...）システムが正常にシャットダウンされていません。
次に再起動すると、各ファイルシステムがチェックされます。
異常終了時にマウントされていないすべてのファイルシステムはすばやく消去されます。
質問1：この結論はスーパーブロックの唯一の解釈から導き出されたものですか？s_状態フィールドやその他の検査はありますか？
Q2:これは異常終了を引き起こす要因によって異なりますか？プライマリドライブに電力が供給されているかどうかによって異なりますか？
Q3:これらのチェックはfsckにファイルシステムをマウントするように指示しますか？
Q4:これらのクリーンアップ状態がコンソールに報告されている間に、カーネル（または他の）ログにこれらのレポートが反映されているものが見つからないのはなぜですか。実際に回復し、最終的にログから回復する必要があるファイルシステムのトレースは次のとおりです。
Linux-5.4/e2fsck 1.46.5/以下オープンソースライブラリ初期化システムとしてユアンシュエ重要な場合は、syslogデーモンとして機能します。
Metalogと最も関連性の高いルール：
Kernel messages :
facility = "kern"
logdir = "/var/log/kernel"
break=1
Fallback:
facility = "*"
minimum = 6
logdir = "/var/log/fallback"
答え1
いくつかの質問をしないでください。
パーティションがmount編集されると、ファイルシステムコードはパーティションのブロック割り当てテーブルをメモリにコピーし、ディスクテーブルを「回復が必要」とマークします。
ファイルシステムコードは、ディスク速度よりもはるかに速いメモリ速度でブロック割り当てを管理します。
インメモリテーブルは定期的にディスクに書き戻されます。これにより、比較的最新の状態を維持し、すべてのテーブルが同時にメモリに保持されるのを防ぎます。
パーティションumountを編集すると、メモリ内テーブルがディスクに書き込まれます（「回復が必要」フラグがクリアされます）。メモリ内テーブルは削除されます。
システムがクラッシュすると、最新のメモリテーブルが失われ、「回復が必要」フラグがまだディスクに設定されています。
ブートにファイルシステムが必要で（エントリ/etc/fstabにファイルシステムが1つありauto）、ディスクに「回復が必要」フラグが設定されている場合は、ファイルシステム固有のファイルfsckシステム（filesystem -makeブロック割り当てテーブルなどfsck.ext4）を実行して「修復」します。 。ext4ファイルシステムの変更」（データ損失の最小化、使用可能なブロックや未使用のブロックがないことを確認するなど）、「修復が必要」のときに作成されたブロックの保存など。独自のテーブルを作成するため、ディスクが編集されfsckない.mountまた、ディスクにはfsck成功するまで「回復が必要」フラグが設定されています。
これらの事前インストールされたシステム誘導fsckアクティビティは、実際にメッセージを記録するのに十分な起動プロセスが「開始」される前に発生しますが、試してみてくださいdmesg。
LusterOneのおかげで
マウントすると、e2fsckはログ内の「回復が必要」フラグをチェックし、ファイルシステムをマウントするために必要なスーパーブロックとグループ記述子ブロックの基本チェックを実行します。 「復旧が必要」が設定されている場合、ログが再生されます。他のエラーが見つかった場合は、ファイルシステムの完全なe2fsckを実行します。 – ラストレワン