Boostの `mapped_file_sink`クラスを使ってメモリマップファイルをフラッシュする方法はありますか？

Question

ブーストライブラリの使用version 1.62.0およびmapped_file_sinkクラスはBoost.IOStreamsです。

書き込まれたデータをディスクat willにフラッシュしますが、mapped_file_sink::flush()メンバー関数はありません。

私の質問は以下のとおりです。

• mapped_file_sinkを使用するとき、どのように私は、書き込まれたデータをフラッシュすることができますか？
• 上記のことができない場合は、msync()とFlushViewOfFile()を移植可能な実装で使用できると考えてみてください。

Answer 1

あなたはhttps://ned14.github.io/boost.afio/classboost_1_1afio_1_1v2__xxx_1_1map__handle.htmlで提案Boost.AFIO v2のマップされたファイルのサポートを見れば、あなたにもマップされたファイルのビューをフラッシュする能力の欠如に気付くでしょう。

マッピングされたビューがあらゆる点でそのファイルのキャッシュされたバッファと同一である場合、現代の統合ページキャッシュカーネルでは重複しているためです。 msync()はそのようなカーネルでは動作しません。なぜなら、ダーティページは、システムが適切であると判断したときに、ストレージに書き込むためにすでにキューに入れられているからです。古いファイルfsync()を使用して、そのファイルのすべてのダーティページの書き出しが完了するまで、プロセスをブロックすることができます。

（a）カーネルが統一されたページキャッシュ設計（QNX、NetBSDなど）ではない、または（b）ファイルがネットワークファイルシステム上にある場合、上記はすべて該当しません。あなたが（a）の状況にある場合は、単にメモリマップされたI/Oを完全に避けるのが最善で、ちょうどread()とwrite()を実行するだけで、パフォーマンスの低下に苦しんでいるOSはあまりありません。 （b）の状況では、ネットワークファイルシステムでメモリマップされたI/Oを使用することは非常に奨励されています。不変ファイルのみの読み取り専用マップの引数があります。それ以外の場合は、は実行していることがわからない限りになりません。 read()とwrite()に戻れば、それはより安全で、驚くことはありません。

最後に、安全なファイル削除プログラムにリンクしました。これらのプログラムは、エクステントの割り当てが遅れたり、ライト・アロケーションでコピーされたりするため、最近のファイルシステムでは信頼性を失っています。つまり、既存のファイルのセクションを書き換えると、ストレージ上の元のデータは変更されませんが、実際には新しいストレージが割り当てられ、新しいリンクリストのファイルのエクステントリストがポイントされます。これにより、予期せぬデータ損失の後に一貫性のあるファイルシステムを簡単に復元することができます。最近のファイルシステム上のデータを安全に削除するには、通常は特別なOS APIを使用する必要がありますが、すべてのファイルを削除して空き領域を無作為のデータで埋めると、ほとんどのデータが安全に削除されます。注記書き込みファイリングシステムでは、次回のガベージコレクションルーチンの起動時またはスナップショットの削除時まで、解放されたエクステントを空き領域プールに戻して新しい割り当てを行うことはできません。このような状況では、空き領域を無作為に埋めても問題のファイルは確実に削除されません。これが問題であれば、ファイリングシステムとしてFAT32を使用してください。シンプルでデータを書き直すと、実際には同じデータがストレージに書き直されます（SSDなどのデータも書き換えない可能性が高い新しいストレージへの変更を書き出し、解放されたエクステントを後で収集する）。