Re: aio_fsync() a directory ?

[Xavier Roche <roche+kml2 at exalead dot com>]

On 04/24/2013 04:48 AM, Christoph Hellwig wrote:
> This change is completely contrary to real world behaviour.  No modern
> filesystem I know of implements this behaviour as the default, and performance
> with the coresponding mount options (usually -o dirsync on Linux) is terrible
> as it forces a write out of the log (or corresponding action on non-log based
> filesystems) and in the common case of volatile write caches a cache flush.
>
> Retrospectively claiming this as standards behaviour in a "clarification"
> is utterly wrong.

As I understand the wording, the original intent was to have all file 
operations synchronized (ie. operation committed permanently) at the 
"beginning" of the specification. The updated one suggests that an 
implementation may be non-conformant, and allow fsync() on a directory 
entry.

I'm also a bit puzzled by the default synchronization guarantee (which 
would lead an I/O per open/rename/etc. operation ?) ; even if many 
developers just do not care about filename synchronization. [ they are 
probably assuming that the fsync() on the file itself will also flush 
the related directory entrie(s) ]