On Fri, 2011-03-18 at 12:04 +1100, NeilBrown wrote: > On Thu, 17 Mar 2011 19:53:07 -0400 Trond Myklebust > <Trond.Myklebust@xxxxxxxxxx> 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@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
