[gmx-developers] Re: flushing files

[Sander Pronk]

I don't know why this post didn't make it to the list but I'm sending it again:


On Oct 13, 2010, at 08:37 , Roland Schulz wrote:
> 
> 
> On Wed, Oct 13, 2010 at 2:05 AM, <hess at sbc.su.se> wrote:
> Hi,
> 
> I think there is no fundamental reason why we can not flush
> only at checkpointing. I don't recall what the originial motivation
> was for flushing every frame. This was probably done before we use
> the whole output file list in the checkpointing code, so the only
> reason might have been because of checkpointing.
> I like that I always have every frame immediately, but having it
> up to at most 15 minutes ago is also fine.
> The question is if we should only flush at checkpointing by default
> or have a switch or some automated setting (we could even catch
> a signal to flush immediately).
> What would you prefer? 
> I think we should try to keep it as simple as possible (I think we already have to many features too seldom used with the potential to introduce bugs). Thus I'm not sure whether automated setting or signal is the best way to go. I don't see a good reason to flush thus I would go with a hidden option to enforce flushing. But that's just my 2c.
> 


It was actually fsyncing that was a big issue. All files are (or should be) fsync()-ed at checkpoint, right after they've been flushed. On filesystems like AFS the flush doesn't do very much by itself: the situation is therefore already as you describe - and it works fine.

BTW When mdrun catches a TERM/INT signal, a checkpoint is written as soon as possible (i.e. at the next neighbour-searching steap) which flushes and fsyncs. So, in principle, we have all the functionality we need.

Sander



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20101013/fc08f0ba/attachment.html>