Re: aio_fsync() a directory ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux