Re: Small O_SYNC writes are no longer NFS_DATA_SYNC

[Trond Myklebust <Trond.Myklebust@netapp.com>]

On Fri, 2011-03-18 at 12:04 +1100, NeilBrown wrote:
> On Thu, 17 Mar 2011 19:53:07 -0400 Trond Myklebust
> <Trond.Myklebust@netapp.com> wrote:
> > Would it ever be wrong to set the FILE_SYNC flag for the very last rpc
> > call in a writeback series? I'm thinking that we might want to set
> > FLUSH_STABLE before the call to pageio_complete in
> > nfs_writepage_locked() and nfs_writepages().
> 
> Interesting idea.
> 
> Am I correct in assuming you only mean if wbc->sync_mode == WB_SYNC_ALL.
> It wouldn't seem to make any sense for WB_SYNC_NONE.
> 
> In that case that last RPC would be immediately followed by a COMMIT. So it
> could be reasonable to make it NFS_DATA_SYNC.

No. DATA_SYNC _requires_ a COMMIT to ensure that metadata is synced too,
so it makes little sense to use it here.

> However the server would be seeing something a bit odd - a sequence of
> unstable writes, then a stable write, then a commit.  This could cause it to
> 'sync' things in the 'wrong' order which might be less than optimal.  It
> would depend a lot on the particular server and filesystem of course, but it
> seems to be mis-communicating.  So I think I would avoid this approach
> (assuming I understand it correctly).

Yes. Thinking a bit more about it, the latest versions of the Linux
server actually do use vfs_fsync_range(), so it no longer makes sense to
replace COMMIT with a FILE_SYNC write.

However we could adopt the Solaris convention of always starting
writebacks with a FILE_SYNC, and then falling back to UNSTABLE for the
second rpc call and all subsequent calls...

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com