私のルートパーティションはext4ファイルシステムでフォーマットされています。
コンピュータがクラッシュしてハードリセットする必要があるたびに再起動し、ルートファイルシステムを確認すると、この手順は完全にシャットダウンされたシステムから起動するよりも少し時間がかかります（たとえば、1〜2秒）。それは「きれい」と報告されています（そして彼とはまったく異なります/dev/<rootpartition> was not cleanly unmounted, check forced）。ファイルシステムが92％満たされました（352GiB）。
私の質問：これがext4の正常で安全な動作なのか、それとも起動スクリプトのバグなのか知りたいのです。 ext4のfsckがext3よりはるかに高速であることはわかっていますが、システムクラッシュ後に「クリーン」と報告されるのは心配です。
そのパーティションで手動で実行すると、e2fsck -fスキャン期間はext2 / ext3ファイルシステムに似ています。だからtune2fs -c 1私はe2fsck -fすべてのブート（
明確にするために編集します。通常、/ var（例：reiserfs）で非クリーンリセットされた後、fsckは/ boot（例：ext2）でログエントリを再生し、fsckが実行され、進行状況バーが表示され、「クリーン」実行後に報告されます。ルートファイルシステムでのみ「強制チェック」が行われず、fsckの進行は発生しませんが、他のファイルシステムでは結果がきれいであってもこの現象が発生します。これは心配な違いです！
答え1
ext4はジャーナリングファイルシステムであり、ジャーナリングの主な目的の1つは、破損を引き起こすことなく異常終了から生き残ることであるため、fsckはもはや必要ありません。
簡単に言えば、ext3 / 4などのジャーナリングファイルシステムは（少なくとも）メタデータの変更を書き込みます。二重。まず「ログ」に記録します。その後、ディスクに保存されると、物理ファイルシステムのメタデータが記録されます。 （ログが連続しており、多くの検索が不要なため、ログに書き込む方がはるかに高速です。少なくともディスクではSSDの検索ペナルティが大幅に削減されます。）
追加の数秒はログ再生になることがあります。デフォルトでは、ファイルシステムが完全にアンマウントされていない場合、次のマウントはfsckログを読み取り、既定のファイルシステムにまだない変更を適用します。
簡単に言えば、期待通りに動作するように聞こえます。
答え2
Fsckは通常、ファイルシステムが完全にアンマウントされていない場合（通常はハードリセットが必要な場合）、起動時に実行されます。 fsckはファイルシステムをマウントする前にファイルシステムをチェックし、問題（矛盾、ログ再生不可、孤立inodeなど）が見つかった場合はエラーを報告し、エラーが見つからない場合は「クリーンアップ」します。したがって、あなたの場合は幸運であり、ファイルシステムは大丈夫です。 fsckの内部動作についてもっと知りたい場合は、fsckに関する非常に興味深い記事があります。https://lwn.net/Articles/248180/
答え3
initrd / initramfsで発生しましたfsck（不純なシャットダウン後、この手順には数秒かかり、ログが再生されるように見える多くのディスクアクティビティがあります）。したがって、一般的で詳細なファイルシステムチェックがプライマリシステムで実行されている場合は、すでにきれいです。