Severe problem with formatted write

[Janne Blomqvist]

On Mon, Aug 01, 2005 at 12:45:07PM -0700, Steve Kargl wrote:
> Is RH9 using a mmap file?  This could be strange interaction
> between mmap and truncating a file.  The FreeBSD manual page
> has the following:
> 
>    WARNING!  Extending a file with ftruncate(2), 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.

Sorry if I sound rude, but uh, why again are we bothering with mmap?

Any possible performance advantage in favour of mmap (whether this
advantage exists is another debate AFAIK without any clear cut answer)
is lost in the noise as the library chugs through a boatload of code
for every (scalarized) element in the io-list.

I straced the example provided pr 16339 with 4 different commercial
compilers. None used mmap and performed very well indeed.

As the non-mmap code path is needed anyway (special files etc.), I
suggest disabling the mmap code path. No need to delete it at this
point IMHO, just disabling it is a one-line patch in unix.c. Less code
to worry about. If at some point the other performance issues are
sorted out and someone wants to investigate whether mmap brings
further measurable improvements, the mmap code path can be reenabled
and the mmap related bugs sorted out as a not-so-high priority
project?

PS: Thanks Steve for reviewing my FLUSH patch, and sorry for
forgetting to mention the IOMSG issue.

-- 
Janne Blomqvist