Re: [PATCH] fsync_range, was: Re: munmap, msync: synchronization

[Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]

On Wed, Apr 23, 2014 at 11:15:27PM +0100, Jamie Lokier wrote:
> >  1) It doesn't fail for read-only FDs.  fsync doesn't, and while
> >     standards used to have fdatasync and aio_fsync fail for them,
> >     Linux never did and the standards are catching up:
> > 
> > 	http://austingroupbugs.net/view.php?id=501
> > 	http://austingroupbugs.net/view.php?id=671
> 
> See also for maybe why:
> 
>         http://www.eivanov.com/2011/06/using-fsync-and-fsyncrange-with.html

I don't really see a "why" there, just the observation that fsync and
fsync_range behavior different on NetBSD, which is odd but documented
behavior.

> >  2) I don't implement the FDISKSYNC.  Requiring it is utterly broken,
> >     and we wouldn't even have the infrastructure for it.  It might make
> >     sense to provide it defined to 0 so that we have the identifier but
> >     make it a no-op.
> 
> I presume Linux does the equivalent without needing FDISKSYNC, if and
> only if the filesystem is mounted with barriers enabled, which is the
> default nowadays?

That's correct, at least for modern mainstream filesystems.  Either way
the filesystem would have to implement the cache flush, so those that
don't support it couldn't support FDISKSYNC either.

> Ah, more differences, which I think should be dropped actually.
> 
>    3) Does not implement NetBSD's documented behaviour when length == 0.
>       NetBSD says "If the length parameter is zero, fsync_range() will
>       synchronize all of the file data".  This path does from offset.

Indeed.  AIX also documents the same behavior.

>    4) Other weird range stuff inherited from sync_file_range() on 32
>       bit machines only.  May not be correct with O_DIRECT or
>       filesystems that don't use page cache.

It's not really possible to implement a full Linux filesystem without
touching the pagecache, but I agree that this probably doesn't
belong into the VFS.  sync_file_range is one of these odd layering
violations that calls straight into the pagecache without going into
the filesystem first (readahead is the other one that comes to mind).

> The desired behaviour with zero length, that's obviously a judgement
> call.  I guess that provided NetBSD applications the option to use
> FDISKSYNC without a range :)

It seems to originate from the earlier AIX version, but I think it's
just their way to sync the whole range. I prefer our 0, LLONG_MAX
notation, but given the existing user interface we should stick to it.

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html