mmap200以上のファイルを同時に作成し、それらをプログラムのアドレス空間にマップするために使用して、それらすべてに同時に書き込むプログラム(cで記述)があります。すべて正常に動作しますが、ディレクトリをバックアップすると、同じプログラムによって一度に作成および書き込みされたファイルは、同じディスクにマップされて書き込まれたファイルよりもはるかに高速 (5 ～ 10 倍) にコピーされます (5 ～ 10 倍)。時間。これはある種のファイルの断片化が原因であるとしか想像できませんが、ufs ファイルシステムでこれが可能であるとは思いもしませんでした。
誰にもアイデアはありますか:
1）通常の使用では、ファイルが書き込まれたのと同じ順序で読み戻される可能性が高いため、これを解決しようとするのは良い考えですか？
2) これに対する良い解決策があれば、どうすればよいですか?
ディスクのファイルシステムは ufs です
最終的に、Free BSDのマニュアルページで見つけました
「警告! ftruncate(2) を使用してファイルを拡張し、大きな穴を作成してから、共有 mmap() を変更してその穴を埋めると、深刻なファイルの断片化が発生する可能性があります。このような断片化を回避するには、常に事前にmmap() を介して領域を変更する前に、新しく拡張された領域にゼロを write() することにより、ファイルのバッキング ストアを割り当てます. ページが完全にランダムな順序でディスクにフラッシュされる可能性があるため、断片化の問題は MAP_NOSYNC ページに特に敏感です. "
Linux や Solaris のマニュアル ページにはそのような警告はありませんが、問題は同じように存在するに違いないという結論に達しました。それについてどうするかは別の問題です。ファイルの最終的なサイズが最初に不明な場合、ファイル全体にゼロを書き込むことはお勧めできません。大きなページの使用を強制することはおそらく役立つかもしれませんが、この種のソリューションはプラットフォーム固有のものになります。