Add warning on file-fragmentation issues related to MAP_NOSYNC

This commit is contained in:
Matthew Dillon 2000-12-03 20:17:36 +00:00
parent b2ca55728b
commit fbf8638995

View File

@ -169,6 +169,21 @@ maintained whether you use MAP_NOSYNC or not. This option is not portable
across UNIX platforms (yet), though some may implement the same behavior
by default.
.Pp
WARNING! Extending a file with ftruncate(), thus creating a big hole, and
then filling the hole by modifying a shared mmap() can lead to severe
file fragmentation. In order to avoid such fragmentation you should
always pre-allocate the file's backing store by write()ing zero's into the
newly extended area prior to modifying the area via your mmap().
The fragmentation problem is especially sensitive to MAP_NOSYNC pages,
because pages may be flushed to disk in a totally random order.
.Pp
The same applies when using MAP_NOSYNC to implement a file-based shared
memory store. It is recommended that you create the backing store by
write()ing zero's to the backing file rather then ftruncate()ing it. You
can test file fragmentation by observing the KB/t (kilobytes per transfer)
results from an 'iostat 1' while reading a large file sequentially, e.g.
using 'dd if=filename of=/dev/null bs=32k'.
.Pp
The
.Xr fsync 2
function will flush all dirty data and metadata associated with a file,