Severe problem with formatted write

[Steve Kargl]

On Mon, Aug 01, 2005 at 09:25:59PM +0200, Paul Thomas wrote:
> 
> >>I'd like to help (for example, reverting the patches you quote one by
> >>one until we find the right one), but I can't see the failure you
> >>mention on x86_64-linux (which is the only fast computer I have access
> >>too right now).
> >
> I finally got some time to do just that:
> 
> Working up from 16th March, I hit the right one with:
> 
> 2005-04-09  Bud Davis  <bdavis@gfortran.org>
>        Steven G. Kargl <kargls@comcast.net>
> 
>    PR fortran/19872
>    * io/transfer.c (data_transfer_init): truncate an existing
>    file on the first write.
> 
> transfer.c:1170
>  /* Overwriting an existing sequential file ?
>     it is always safe to truncate the file on the first write */
>  if (g.mode == WRITING
>      && current_unit->flags.access == ACCESS_SEQUENTIAL
>      && current_unit->current_record == 0)
>    struncate(current_unit->s);
> 
> If I comment out the code, the problem (documented below) goes away. 
> Expanding the macro by hand does not help, so the (s)->truncate 
> function must be broken, for RH9 at least.
> 

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.

-- 
Steve