ext4 ではファイル システムの書き込みをどのくらいの期間キャッシュできますか?

ext4 ではファイル システムの書き込みをどのくらいの期間キャッシュできますか?

少し前に、ext4が不正なアンマウント後に空のファイルを残す可能性があるという議論がありましたが、それは非常によくまとめられています。記事上で基本的に、遅延割り当てにより、書き込みは、ext ジャーナルのデフォルトのコミット間隔 (5 秒) よりもはるかに長い時間、書き込みキャッシュに保持されます。

この問題は、特定の状況でブロック割り当てを強制し、デフォルトで最大 5 秒後にデータをディスクに強制的に保存するパッチで修正されたようです。

アプリケーションがファイル自体を切り捨てたり追加したりせずに、ファイルの既存の部分を上書きするとどうなるのか知りたいです。これも 5 秒以内に強制的にディスクに書き込まれるのでしょうか?

これはファイルへの追加とは異なる状況のようです。追加すると、ファイル サイズが変更され、メタデータが変更されます。そのため、5 秒以内にジャーナル コミットが必要になります。また、data=ordered のため、セキュリティ上の懸念から、その前にデータを書き込む必要があります (そうしないと、他のユーザーが削除したファイルの一部が、追加されたファイルの所有者に表示される可能性があります)。

ファイル データを上書きする場合、古いデータは新しいデータと同じユーザーに属しているため、メタデータ ジャーナルのコミット前にデータの書き込みを行う必要はありません。書き込みはコミット前に行われるのでしょうか、それともジャーナル コミット間隔よりも長く遅延されるのでしょうか。そうであれば、どのくらいの期間でしょうか。

更新: 正しいこと、つまり fsync() を使用する場合、これらすべては無関係であることはわかっています。(これが ext4 とデータ損失に関するすべての議論の主な理由です。問題は、アプリケーションが fsync() を実行しないか、適切なタイミングで実行しないことにのみ関係していました。) 私は独自のアプリケーションを作成しているわけではありません。すべてのアプリケーションが正しいことを実行しているかどうかわからないため、また、このような「危険な」書き込みのおおよその時間枠を知りたいため、質問しています。質問する理由は、グラフィックス ドライバーが定期的にカーネル パニックを引き起こすため、最後の 5 秒以上のデータ書き込みについて心配する必要があるかどうかを知りたいからです。

答え1

コミット間隔をカスタム値に設定できます。これは、32 ビットの符号なし整数の秒数まで設定できると思います。つまり、約 40 億秒、つまり 136 年です。これはマウントcommitオプションを通じて利用可能で、次のように有効にできます (これは単なる例です。 で設定することもできますfstab)。

mount /dev/sda1 -t ext4 -o rw,data=writeback,nobh,commit=12345678

コミット間隔は、データが追加されるか、既存のデータが上書きされるかなどの条件には基づきません。commitマウント オプション (マウント オプションをまったく指定しない場合はデフォルトで 5 秒になります) は、bash シェルで次のように実行するのと同じです。

#!/bin/bash
while :
do
    echo "Syncing all uncommitted data and journal to disk"
    sync
    sleep 5
done

このグローバルファイルシステム同期間隔と混同しないでくださいdata=ordered(「コミット間隔」は、コマンドラインプログラムの機能を理解している人にとってはあまり意味のない用語かもしれません。syncその場合は「同期間隔」と呼ぶ方が適切かもしれません)data=ordered注文データとメタデータが更新される間隔 (data=writebackは「安全性が低い / 高速」で、data=journalは「安全性が高い / 低速」)。commit=12345678は、ファイルシステム ドライバー自体が、すべてのダーティ データ / ジャーナル / メタデータ / その他すべてを物理メディアに強制的に完全同期する頻度です。 また、必要に応じてこれを 136 年に設定し、data=writeback,nobh呼び出しを行わないプログラムfsync()や、sync()ダーティ ページが RAM に数世代にわたって残るプログラムでマウントすることもできます。

更新: 質問編集のコンテキストに基づいて、グラフィックス ドライバーのカーネル パニックを解決できるまで、マウント オプションdata=journal,commit=1またはsyncマウント オプションを使用してファイル システムを実行することをお勧めします。これにより、最大限のデータ整合性が維持されますが、パフォーマンスは低下します。失うことのできないデータを頻繁にディスクに書き込む場合は特に、この操作を行う必要があります。また、使用しているアプリを適切に使用するために「信頼」していない場合は、これがさらに重要になりますfsync()

ソース: ここ個人的な経験

答え2

あなたの質問に対する答えが何であれ、それは重要ではありません。

保証された露出syncext4 ファイルシステムの動作は、「 /呼び出しが成功した後、データはディスク上に置かれますfsync」です。したがって、この質問をさせるアプリケーションがある場合は、データの整合性を保証する必要がある重要なポイントで同期呼び出しを挿入する必要があります。同じ問題を心配しているユーザーの場合は、syncクリーンでないシャットダウンを引き起こす可能性のある危険な動作を行う前に、コマンドライン ユーティリティを呼び出すことができます。

関連情報