2
ext4でファイルシステムの書き込みをキャッシュできる期間
しばらく前、汚れたアンマウント後に空のファイルを残す可能性のあるext4についての議論がいくつかありました。基本的に、遅延割り当てのために、extジャーナルのデフォルトのコミット間隔(5秒)よりもはるかに長い時間、書き込みを書き込みキャッシュに保持できます。 この問題は、特定の状況でブロックの割り当てを強制するパッチで修正されたようで、デフォルトで最大5秒後にデータをディスクに強制します。 ファイル自体を切り捨てたり追加したりせずに、アプリケーションがファイルの既存の部分を上書きするとどうなるのかと思います。それも5秒以内にディスクに強制されますか? ファイルへの追加とは異なる状況のようです。追加すると、ファイルサイズが変更されます。これはメタデータの変更です。したがって、5秒以内にジャーナルコミットが必要になります。data= orderedの場合、セキュリティ上の懸念からデータを書き込む必要があります(そうしないと、他のユーザーの削除済みファイルの一部が追加の所有者に表示される可能性がありますファイル)。 ファイルデータを上書きするだけの場合、古いデータは新しいデータと同じユーザーに属するため、メタデータジャーナルがコミットされる前にデータの書き込みを行う必要がある理由はありません。とにかく、書き込みはコミットの前に発生しますか、それともジャーナルのコミット間隔よりも長く遅延することはできますか?もしそうなら、どのくらいですか? 更新:正しいことを行うとき、つまりfsync()を使用するとき、これらはすべて無関係であることを知っています。(これがext4とデータ損失に関するすべての議論の主な理由でした-問題はアプリケーションがfsync()しない、または適切なタイミングではないことのみに関係していました。)私は自分のアプリケーションを書いていません。すべてのアプリケーションが正しいことを行うかどうかはわかりません。そのような「危険な」書き込みのおおよその時間枠を知りたいです。質問する理由は、グラフィックスドライバーが定期的にカーネルパニックを引き起こすため、データ書き込みの最後の5秒以上を心配する必要があるかどうかを知りたいからです。
14
filesystems
ext4