ジャーナルファイルシステムを起動するときのfsckの重要性は何ですか？

私は「ジャーナリングファイルシステム」の一般的な文脈でこの質問に答えています。

私の考えで、あなたが「不純な終了」をたくさんしたら（を通して）電源コードのようなものを引っ張りますか？fsck）近いうちにfsckまたはそれに対応する道徳的なコマンドである.fileystsmが必要なファイルシステムの状態に陥ります。xfs_repair私のラップトップの.fileystsmはext4ほとんど完全なシャットダウンを含む再起動するたびにログを再生しますが、時には完全なログを実行します。fsck。

しかし、「日誌をもう一度読んでみること」で何が得られるのか、自分に聞いてみてください。ログを再生すると、ファイルシステムの残りの部分のディスクブロックがログエントリに必要な順序と一致することを確認できます。再生日記は日記の一部であるfsckか、日記全体の一部ですfsck。

私の考えにはいくつかの言語的詐欺が進んでいるようです。再生ログの役割は従来の役割の一部であり、プログラム（または他のファイルシステム）とまったく同じfsckです。xfs_repairXFSの人々は、彼らの経験のために起動するたびに実行されず、ログのみが再生されると信じられます。e2fs.fsckfsckxfs_repair

異常終了後もファイルシステムが一貫した状態を維持するのに役立ちます。

最初に注目すべき点は、ほとんどのXFS、reiser、およびext構成がfsckを防ぐためにメタデータロギングのみを実装することです。ログは起動時に常に再生されるわけではありません。不完全な場合は廃棄されることがあります。

一部のシステムは完全なデータロギングをサポートしていますが、実際にはこれらのシステムは実際のシナリオで非常に低いレベルの保証でメタデータロギングのみを提供します。

したがって、「一貫性のない状態」とfsckが解決する問題は、メタデータとファイル自体の間の矛盾です。これを防ぐために、オペレーティングシステムは提案されたメタデータの変更をログに記録し、実際のデータをディスクに書き込み、ログからコピーされたメタデータの変更をディスクに適用します。唯一の問題は、ディスクコントローラが要求をバッファリングして並べ替えることができることです。これを防ぐために、ほとんどのジャーナリングファイルシステムはバリアを実装しています。バリアは各ジョブを分離し、ディスクがジョブが完了したことを確認するのを待ちます。しかし、多くの最新ディスクは、実際にデータをコミットする前に書き込みの完了を認識しています。したがって、状況が混乱する可能性があります。

異常終了後もfsckはまだ必要ですか？なぜ

ほとんどのファイルシステムはマウント数を保持します。この回数に達すると、次回ディスクをマウントしようとすると fsck 全体がトリガーされます。これは、明示的に記録されていないかソフトウェアにバグがない場合でもディスクデータが破損する可能性があるためです。上記のpsusiコメントが間違っています。

単に異常終了したため、ジャーナルファイルシステムをfsckする必要はありません。

これみんなメタデータロギングの実行時パフォーマンスの低下を許容する理由は、ファイルシステムが完全にアンマウントされていない場合は、次のマウント時にメタデータログを自動的に再生してファイルシステムが100％一貫性を維持できることです。

fsckの唯一の役割はメタデータの一貫性を保証することであるため、ファイルシステムが正しくマウント解除されなかったため、fsckの実行は重複します。

ただし、ジャーナリングファイルシステムは、ハードウェアエラー、ドライバエラー、管理エラーなどの他の理由で破損する可能性があるため、fsckツールが必要です。ただ、異常終了のために電話する理由はありません。