XFSはシステムブート時にfsckを実装していないことに気づきました。ファイルシステムのジャーナリングが原因でファイルシステムが一貫性のない状態で確実にシャットダウンされた後、ファイルシステムが一貫した状態になることを推奨する理由の1つです。次のマウント時（再起動後など）に、ジャーナルが再生されます。
クリーンシャットダウン後もfsckが必要ですか？なぜですか？
XFSはシステムブート時にfsckを実装していないことに気づきました。ファイルシステムのジャーナリングが原因でファイルシステムが一貫性のない状態で確実にシャットダウンされた後、ファイルシステムが一貫した状態になることを推奨する理由の1つです。次のマウント時（再起動後など）に、ジャーナルが再生されます。
クリーンシャットダウン後もfsckが必要ですか？なぜですか？
回答:
「ジャーナル化されたファイルシステム」の一般的なコンテキストでこれに答えています。
（電源コードなどを引っ張ることによって）いくつかの「クリーンでないシャットダウン」を実行した場合、遅かれ早かれfsck、fsck を必要とするファイルシステムの状態または道徳的に同等のものになると思いますxfs_repair。ext4私のラップトップ上のfileystsmは、ほとんどの場合、再起動のたびにジャーナルを再生しますが、クリーンシャットダウンが含まれていますが、たまにフルオンになりfsckます。
しかし、「ジャーナルの再生」が何を達成するかを自問してください。ジャーナルを再生すると、ファイルシステムの残りのディスクブロックがジャーナルエントリが要求する順序と一致することが保証されます。ジャーナルを再生することは、小さなものfsck、または全体の一部に相当しfsckます。
私は、いくらか口頭で巧妙に取り組んでいると思います。ジャーナルの再生fsckは、従来の機能の一部であり、xfs_repairまさにe2fs.fsck（または他のファイルシステムのfsck）プログラムと同じ種類のプログラムです。XFSの人々はただ信じているか、その経験からxfs_repair、すべてのブートで実行するのではなく、ジャーナルを再生するだけでした。
fsck巻きは「独創的」ではありません。私が理解しているように、ext3 LVMパーティションを変換し、ext4ext4_mb_generate_buddyエラーが発生し始めました。ext4これは、変換された「LVM」パーティション上のビットマップのディスク上とメモリ内のコピーに不一致を引き起こしたコードのバグが原因です。からわかる限りfsck、破損は発生していません。解決策は、UNINIT_BGオプションをオフにするか、データを移動してパーティションをとして再初期化することext4でした。後者のコースをとりました。しかし、私はまだ数分待ってからfsckデータを失う価値はないと思います！
クリーンでないシャットダウンの後、ファイルシステムが一貫した状態にあることを確認するのに役立ちます
最初に注目すべきことは、XFS、Reiser、およびextのほとんどの構成がメタデータジャーナリングのみを実装していることです。これはすべてfsckを回避することに関するものです。ジャーナルは起動時に常に再生されるわけではありません-不完全な場合は破棄される可能性があります。
完全なデータジャーナリングをサポートするシステムはありますが、実際には、メタデータジャーナリングに対してこれらが与える保証のレベルは、実際のシナリオでは非常に小さいものです。
したがって、「矛盾した状態」とfsckによって修正された問題は、メタデータとファイル自体の不一致です。これを回避するために、OSは提案されたメタデータの変更をジャーナルに書き込み、次に実際のデータをディスクに書き込み、ジャーナルで複製されたメタデータの変更をディスクに適用します。これの唯一の問題は、ディスクコントローラが要求をバッファリングし、場合によっては要求を並べ替えることです。これを回避するために、ほとんどのジャーナリングファイルシステムはバリアを実装しています。バリアは各操作を分離し、ディスクが操作を完了したことを確認するまで待機します。しかし、最近の多くのディスクは、データがコミットされる前に実際に書き込みの完了を確認します。したがって、物事は混乱する可能性があります。
クリーンでないシャットダウン後もfsckがまだ必要ですか？その理由
ほとんどのファイルシステムはマウント数を維持します-この数に達すると、ディスクをマウントする次の試行で完全なfsckがトリガーされます。その理由は、ソフトウェアにバグがなくても、明示的に書き込まれていない場合でもディスクデータが破損する可能性があるためです。上記のpsusiのコメントは間違っています。
hdparm -W）、ディスクはメディア上に存在するまで書き込み要求を完了しません。なぜそのオプションが存在すると思いますか？バリアは、複数のリクエストが発行されたときの並べ替えを防ぎます。バリアがない場合、fsは前のリクエストが完了するまでリクエストを発行しないため、ディスクの書き込みキャッシュが有効になっていない場合、バリアなしで順序付けが維持されます。バリアの目的は、クラッシュ時にfsを破壊することなく、書き込みキャッシュを有効にできるようにすることです。
sync。もう一度やってみましょう。バリアなしでディスクに書き込む手順は、ジャーナルに書き込むことですsync。これにより、書き込みキャッシュをフラッシュしてから、実際のデータを書き込みます。これにより、クラッシュ後にfsを回復するためにジャーナルを常に使用できるようになりますが、同期すると処理が遅くなり、書き込みキャッシュの目的が半分損なわれます。したがって、バリアはのより優れた代替として追加されsync、適切なディスクサポートにより、同期が奪うパフォーマンスの多くを安全に取り戻すことができます。
シャットダウンが不適切なためにジャーナリングファイルシステムをfsckする必要はありません。
全体のメタデータジャーナリングの実行時のパフォーマンスの低下に耐えた理由は、ファイルシステムが正常にアンマウントしなかった場合、ファイルシステムは、自動的に次のマウント上のメタデータのログを再生することによって、再び100％の一貫した行うことができることを確実にするためです。
fsckの唯一の役割はメタデータの一貫性を確保することです。そのため、ファイルシステムが適切にアンマウントされなかったという理由だけでfsckを実行することは冗長です。
ただし、ジャーナリングファイルシステムは、他の理由（ハードウェア障害、ドライバーのバグ、管理エラーなど）で破損する可能性があるため、fsckツールが必要です。シャットダウンが不適切であるという理由だけでこれらを呼び出す理由はありません。