問題タブ [fsync]

私はかなり重要なデータを処理するためにいくつかのソフトウェアを書いています、そして耐久性を達成するために私が何をする必要があるかを正確に知る必要があります。

どこを見ても矛盾する情報があるので、洞察をいただければ幸いです。

ディスクに書き込む方法は3つあります。

• O_DIRECTの使用| O_DSYNC、および512バイトをプリアドしてからpwriteする-16MBブロック。

• O_DIRECTを使用して、512バイトブロックをプリアドしてからpwriteし、必要に応じて定期的にfdatasyncを呼び出します。

• 必要に応じて定期的にmsync（...、MS_SYNC | MS_INVALIDATE）と呼ぶメモリマップトファイルを使用します。

そして、これはすべてデフォルトフラグ付きのext4にあります。

これらすべてについて、停電、パニック、クラッシュなどによってデータが失われたり（書き込みまたは同期が戻った後）、破損したりする可能性はありますか？

サーバーがpwriteの途中で、またはpwriteの開始とfdatasyncの終了の間に、またはマップされたメモリが変更されてmsyncの間に停止した場合、古いデータと新しいデータが混在する可能性がありますか、それとも1つになりますか？または他？個々のpwrite呼び出しをアトミックで順序付けてほしい。これは本当ですか？そして、それらが複数のファイルにまたがっている場合はそうですか？したがって、O_DIRECTで書き込む場合| O_DSYNCをAに、次にO_DIRECT | O_DSYNCからBへ、何が起こっても、データがBにある場合、それはAにもあることが保証されますか？

fsyncは、データが書き込まれることを保証しますか？そうではありませんが、それ以来状況が変わったかどうかはわかりません。

ext4のジャーナル化は、このSOの回答が存在すると言っている破損したブロックの問題を完全に解決しますか？

私は現在、posix_fallocateを呼び出してからftruncateを呼び出してファイルを増やしています。これらは両方とも必要ですか、それで十分ですか？これらの問題を回避するために、ftruncateが実際に割り当てられたブロックを初期化すると考えました。

ミックスに混乱を加えるために、私はこれをEC2で実行していますが、それが何かに影響するかどうかはわかりません。どれだけ積極的にシャットダウンするかを制御できないため、テストは非常に困難ですが。

レコードが永続化されたと報告したときに、それが実際に永続化されたものであることを可能な限り保証するアプリが必要です。これを行うには を使用することを理解していますfsync(fd)。しかし、何らかの奇妙な理由で、fsync() を使用すると、ディスクに書き込むコードが期待どおりに遅くなるのではなく、速度が上がるようです。

一部のサンプル テスト コードは、次の結果を返します。

以下は、これらの結果を生成するコードです。

fsyncへの呼び出しの前にへの呼び出しを発行しfstatて、ターゲット ファイルのファイルサイズを決定するレガシー コードがあります。(具体的には、コードは stat 構造体から st_size にのみアクセスしています。)

ドキュメントを見て、これは必要な電話だとは思いませんが、専門家の意見が欲しかったのです。

次のようなログ ファイルに書き込む 2 つの (POSIX) スレッドがあります。

ファイルはモード "a" でmain()開かれます。プロセスが実行されている間、またはプロセスが終了してファイルが-ed になった後fopen()でも、ファイルに何も表示されませんが、行はすべてそこにあります。cattailfclose()

私は何を間違っていますか？

タイトルに記載されている例外を受け取っているお客様はかなり多いのですが、どのデバイスでも再現できません。

バグレポートは、エラーがSonyデバイスでのみ発生することを示唆しているようですが、SonyがAndroid上のデータベースで何か面白いことをしているというレポートは見つからないようです。

この例外をトリガーするコードはトランザクションを終了しています

ここからのスタックトレースは次のとおりです。

データベースは外部ストレージに存在します（ただし、顧客の報告によると、外部ストレージがマウントされている場合に発生します）。

コードについてあまり厳しくしないでください。たとえば、endTransactionが最終的に含まれるSQLステートメントの周りにtry / catchがあるはずですが、この場合は違いはありません（私は違いません）現時点でこのレガシーの混乱をクリーンアップするためのリソースを入手してください）。

AIXでSQLITE_IOERR_DIR_FSYNCに関する古いレポートがいくつか見つかりました。ディレクトリでのfsync（）はサポートされていませんでしたが、AndroidでSQLiteを正しいコンパイラフラグで再準拠できないため、実際には役に立ちませんでした...

何か案は？

MongoDB で fsync() 操作を実行しましたが、すぐに返されます。何もしていないようです。データが実際にディスクにフラッシュされたかどうかを確認するにはどうすればよいですか?

注: syncdelay を 0 に設定しました。これは、書き込みが 60 秒ごとに自動的に fsync されないことを意味します。

私の実際のコマンドはperlドライバーを使用しています：

ありがとう。

データがディスク上にあることを確認するための情報 ( http://winntfs.com/2012/11/29/windows-write-caching-part-2-an-overview-for-application-developers/ ) から、たとえば、停電の場合、Windows プラットフォームでFlushFileBuffersは、バッファが実際にディスク デバイス キャッシュからストレージ メディア自体にフラッシュされるという最良の保証を得るために、その「fsync」バージョンに依存する必要があるようです。と の組み合わせは、デバイス キャッシュのフラッシュを保証するものFILE_FLAG_NO_BUFFERINGでFILE_FLAG_WRITE_THROUGHはなく、この情報が正しい場合、ファイル システム キャッシュに影響を与えるだけです。

「トランザクション的に」更新する必要があるかなり大きなファイルで作業するという事実を考えると、これはトランザクションコミットの最後に「fsync」を実行することを意味します。そこで、その際のパフォーマンスをテストするための小さなアプリを作成しました。基本的に、8回の書き込みを使用して8メモリページサイズのランダムバイトのバッチの順次書き込みを実行し、次にフラッシュします。バッチはループで繰り返され、多くのページが書き込まれるたびにパフォーマンスが記録されます。さらに、2 つの構成可能なオプションがあります。フラッシュ時に fsync を実行するか、ページの書き込みを開始する前に、ファイルの最後の位置にバイトを書き込むかどうかです。

私が得ているパフォーマンス結果 (64 ビット Win 7、遅いスピンドル ディスク) は、あまり期待できるものではありません。「fsync」のパフォーマンスは、フラッシュされる「ダーティ」データの量ではなく、フラッシュされるファイルのサイズに大きく依存するようです。下のグラフは、小さなベンチマーク アプリの 4 つの異なる設定オプションの結果を示しています。

ご覧のとおり、「fsync」のパフォーマンスは、ファイルが大きくなるにつれて指数関数的に低下します (数 GB で実際に停止するまで)。また、ディスク自体はそれほど多くのことをしていないようです (つまり、リソース モニターは、そのアクティブな時間を数パーセント程度しか示しておらず、そのディスク キューはほとんどの時間ほとんど空です)。

「fsync」のパフォーマンスは、通常のバッファリングされたフラッシュよりもかなり悪いと予想していましたが、多かれ少なかれ一定で、ファイルサイズに依存しないと予想していました。このように、単一の大きなファイルと組み合わせて使用​​ できないことを示唆しているようです.

誰かが説明、異なる経験、またはデータがディスク上にあることを保証し、多かれ少なかれ一定の予測可能なパフォーマンスを持つ別のソリューションを持っていますか?

UPDATED 以下の回答の新しい情報を参照してください。