如何使用Boost的`mapped_file_sink`類刷新內存映射文件？

Question

使用Boost庫版本1.62.0和mapped_file_sink從類了Boost.Iostreams 。

我要刷新寫入的數據到磁盤的意願 ，但沒有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() ，它們在當今操作系統中所占的比例很小，因此它們的性能很差。 對於（b）情況，強烈建議您不要對網絡文件系統使用內存映射的I / O。 有一個參數僅適用於不可變文件的只讀映射，否則除非您知道自己在做什么，否則不要這樣做 。 退回到read()和write() ，它更安全，並且不太可能出現意外。

最后，您鏈接到一個安全的文件刪除程序。 由於延遲的擴展區分配或寫入時復制，這些程序在最新的文件系統上無法再可靠地工作。 換句話說，當您重寫現有文件的一部分時，它不會修改存儲中的原始數據，而是實際上分配新的存儲，並將文件的擴展區列表指向新的鏈接列表。 這樣可以在意外數據丟失后輕松恢復一致的文件系統。 為了安全地刪除最新文件系統上的數據，您通常需要使用特殊的OS API，盡管刪除所有文件然后用隨機數據填充可用空間可能會在大多數情況下安全地刪除大部分有問題的數據。 注意，寫文件系統上的副本可能要數天或數周才能將釋放的擴展區釋放回空閑空間池以進行新的分配，直到下一次垃圾回收例程觸發或快照被刪除為止。 在這種情況下，隨機填充可用空間將無法安全刪除有問題的文件。 如果所有這些都是問題，請使用FAT32作為文件系統，這非常簡單，並且在其上重寫數據確實可以重寫存儲上的相同數據（盡管請注意，某些存儲介質（例如SSD）也很可能不會重寫數據，這些也稍后對新的存儲和垃圾收集釋放的擴展區進行修改）。