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) ]
-- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
