[Lustre-devel] Flush on file close

Andreas Dilger andreas.dilger at oracle.com
Mon Apr 19 21:04:12 PDT 2010

On 2010-04-19, at 12:30, Andrew Perepechko wrote:
> Some applications expect non-zero errno on close() for any errors  
> that may
> happen during flushing dirty cached data/metadata even though linux  
> manual
> page for close(2) suggests that fsync(2) should be used prior to  
> close(2) in
> order to detect problems like those.
> Since syncing may degrade performance to a large extent, what do you  
> think is
> the best/most convenient/least intrusive way to switch to that  
> behaviour?
> Should it be a mount option for the client or anything else?

If the application is expecting the "flush all outstanding data"  
semantics of fsync() on close, it should just call fsync() and use the  
return code of that instead of overloading close() to do it.  There  
will be no worse performance by waiting for fsync() to complete, than  
waiting for a close that is flushing all of the data.

In contrast, if an application is NOT expecting synchronous flushing  
on close, then making every close flush all data WILL be a major  
performance impact.  Better to have applications do what they mean,  
and system calls do what they are supposed to, instead of adding in  
extra semantics that not every application wants.

Also, as Oleg wrote, if an application is doing close/open when it is  
really just trying to flush the data to disk (which I saw some traces  
of recently) then this is even WORSE than just doing an fsync().

Cheers, Andreas
Andreas Dilger
Principal Engineer, Lustre Group
Oracle Corporation Canada Inc.

More information about the lustre-devel mailing list