[adding Tom to Cc for a little spec clarification] On Thu, Nov 06, 2014 at 03:13:41PM -0500, J. Bruce Fields wrote: > > Makes sense to me.--b. > > Applying for 3.19.--b. Looking at the specs again I have a little doubt about DATA_SYNC vs NFSv4. RFC3530, 14.2.36. sais: "If stable is DATA_SYNC4, then the server must commit all of the data to stable storage and enough of the metadata to retrieve the data before returning." So far so good, and exactly matches our fdatasync semantics, which force out the inode itself, and any indirect blocks or extent tree information, ignoring only time stamp updates. But for NFSv4 there is a consideration that we don't have for local access: the change attribute. For most exportable filesystems we use the ctime timestamp for that, which does not get persisted by fdatasync. Unfortunately the whole language about DATA_SYNC is so vague that I'm tempted to withraw my patch due to this issue. Note that for filesystems natively implementing the change attribute (btrfs, XFSv5 and ext4 with a mount option) there is no difference anyway, as they update the change attribute on every write, which doesn't fall under the fdatasync umbrella, although I think it generally should, as it would render fdatasync useless on thee otherwise. Summary: a patch like mine above probably doesn't make sense, and as far as I can tell we should deprecate use of DATA_SYNC4 for NFSv4, because it cannot be different from FILE_SYNC4 due to the specification for the change attribute. -- 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
