ext4はハードリセット後にfsckによってクリーンであると報告されました：それは正常ですか？
私のルートパーティションはext4-filesystemとしてフォーマットされています。
マシンがクラッシュしてハードリセットする必要があるときはいつでも、再度起動してルートファイルシステムをチェックすると、この手順は、完全にシャットダウンされたシステムから起動する場合よりも少し長く（1〜2秒など）かかります。しかし、それは「クリーン」として報告されます（そして/dev/<rootpartition> was not cleanly unmounted, check forcedのようなものは何もありません）。ファイルシステムは92％フル（352 GiB）です。
私の質問：これはext4の正常で安全な動作なのか、それともスタートアップスクリプトのバグなのか疑問に思います。 ext4のfsckはext3よりもはるかに高速であることは知っていますが、システムクラッシュ後に「クリーン」と報告されるのではないかと心配しています。
そのパーティションでe2fsck -fを手動で実行すると、チェックはext2/ext3ファイルシステムと同等に続きます。だから私は心配していて、ビーイングをしているので、起動のたびにチェックされるようにファイルシステムを調整しました（tune2fs -c 1）。その結果、起動のたびにe2fsck -fの完全なチェックが必要になります。
明確にするために編集します。クリーンでないリセットの後、通常、reiserfsである/ varで、fsckはジャーナルエントリを再生します。 ext2である/ bootで、fsckが実行され、進行状況バーが表示され、実行後に「クリーン」と報告されます。ルートファイルシステムでのみ、「強制チェック」やfsck-progressは表示されません。これらは、他のファイルシステムがクリーンであることが判明した場合でも表示されます。それが心配な違いです！
fsckはすでにinitrd/initramfs内で実行されています（クリーンでないシャットダウン後は、ジャーナルが再生されているように見えるこの段階で多くのディスクアクティビティが発生すると、数秒長くかかります）。 、より詳細な、ファイルシステムチェックはメインシステムから実行されており、すでにクリーンです。
ext4はジャーナリングファイルシステムであり、ジャーナリングの主な目標の1つは、損傷のないクリーンでないシャットダウンに耐えることであり、したがって、長いfsckを必要としません。
要するに、ext3/4のようなジャーナリングファイルシステムはメタデータを（少なくとも）変更を書き込みます2回。まず、それらを「ジャーナル」に書き込みます。次に、それがディスク上にあると、実際のファイルシステムメタデータに書き込みます。 （ジャーナルはシーケンシャルであり、大量のシークを必要としないため、ジャーナルへの書き込みははるかに高速です。少なくとも磁気ディスクでは、SSDではシークペナルティが大幅に削減されます。）
数秒余分にジャーナルが再生される可能性があります。基本的に、ファイルシステムが正常にアンマウントされていない場合、次のマウントまたはfsckがジャーナルを読み取り、メインファイルシステムにまだない変更を適用します。
つまり、要するに、期待どおりに動作しているように聞こえます。
Fsckは通常、ファイルシステムが正常にアンマウントされていない場合（通常はハードリセットが必要な場合）に起動時に実行されます。 fsckは、ファイルシステムをマウントする前にチェックし、問題（不整合、ジャーナルの再生の失敗、孤立したiノードなど）を検出するとエラーを報告します。エラーを検出しない場合は「クリーン」と報告します。したがって、あなたの場合、あなたは幸運に恵まれ、あなたのファイルシステムは大丈夫です。内部でどのように機能するかについてさらに情報が必要な場合は、fsckに関する非常に興味深い投稿があります： https://lwn.net/Articles/248180/