私のルートパーティションは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ログを読み取り、既定のファイルシステムにまだない変更を適用します。
簡単に言えば、期待通りに動作するように聞こえます。