web-dev-qa-db-ja.com

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

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

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

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

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

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

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

filesystemsext4
14
lxgr

コミット間隔をカスタム値に設定できます。これは、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_は、データとメタデータが更新されるorderについてです（ここで、_data=writeback_は「安全性が低い/高速」であり、_data=journal_は "より安全/遅い」）。 _commit=12345678_は、ファイルシステムドライバー自体がすべてのダーティデータ/ジャーナル/メタデータ/物理メディアへの完全な同期を強制する頻度についてです。そして、あなたが望むなら、あなたはそれを136年に確実に設定することができ、_data=writeback,nobh_でマウントすることができ、fsync()またはsync()を呼び出さないプログラムはダーティページを配置しますRAM for ...いくつかの寿命。

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

出典：ここ および個人的な経験

16
allquixotic

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

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

1
Borealid