[gmx-developers] Re: flushing files

[Sander Pronk]

On Oct 13, 2010, at 11:23 , Berk Hess wrote:

> That probably depends on if you run on 10 or 100000 nodes.

of course. I was wondering whether Roland has any numbers for his systems, and am curious about the scaling: to what extent are we amortizing the cost of writing over multiple sync calls?


> 
> I just discussed the flushing with Erik.
> I forgot the motivation for this, but it was to have only whole frames disks.
> If you don't flush, you'll often have partial frames.
> So the options are: or flush every frame or buffer and then flush or fsync.
> For the mpi i/o this is no issue, since we buffer internally, we can simply
> on fsync on write, which should happen at least when checkpointing.
> 
> I guess the only remaining question is if flushing could be slow under
> circumstances where we would not want to use the mpi buffered i/o?

There are a couple of circumstance that could trigger that: 
- we're writing to an unbuffered file system (nfs in synchronious mode, for example).
- the OS runs out of disk cache (i.e. RAM) and is forced to write out to disk for each write() call. If this happens, there are bigger problems to worry about for the user.

the first case could be real (due to an overzealous system administrator).