On Wed, Apr 24, 2013 at 07:31:14AM +0200, Xavier Roche wrote: > 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. Original intent of _what_? With all due respect, original intent of Austin Group is none of our concern - "we had always intended to make that promise on your behalf, now we'd simply got around to saying so clearly" inspires many things, but "oh, sure, it's binding for us now" is *not* one of those. Suggestions to do anatomically impossible things, OTOH... -- 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
