ext4でファイルシステムの書き込みをキャッシュできる期間

しばらく前、汚れたアンマウント後に空のファイルを残す可能性のあるext4についての議論がいくつかありました。基本的に、遅延割り当てのために、extジャーナルのデフォルトのコミット間隔（5秒）よりもはるかに長い時間、書き込みを書き込みキャッシュに保持できます。

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

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

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

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

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

コミット間隔をカスタム値に設定できます。カスタム値は、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についてです（「安全性が低い/速い」と「安全性が遅い/遅い」）。これは、ファイルシステムドライバー自体がすべてのダーティデータ/ジャーナル/メタデータ/すべてを物理メディアに完全に同期させる頻度です。必要に応じて136年に設定することもできます。また、呼び出しを行わないプログラムや、RAMに座っているダーティページがあるプログラムは...data=writebackdata=journalcommit=12345678data=writeback,nobhfsync()sync()

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

出典： ここと個人的な経験

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

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