On Tue, Nov 11, 2014 at 5:27 AM, Christoph Hellwig <hch@xxxxxx> wrote: > On Mon, Nov 10, 2014 at 12:54:24PM -0500, J. Bruce Fields wrote: >> Shouldn't that be NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR? >> >> The draft says that e.g. "If the client sees >> NFS4_CHANGE_TYPE_IS_VERSION_COUNTER, it has the ability to predict what >> the resulting change attribute value should be after a COMPOUND >> containing a SETATTR, WRITE, or CREATE." >> >> Admittedly, I'm not completely sure what that means. (Is a SETATTR of >> multiple attributes a single atomic change? Can we predict the change >> attribute on a newly created file, or only on the parent directory?) I >> also don't know where the filesystems do the i_version increment (can we >> guarantee it happens once per nfs WRITE?). > > Actually the server may increment it many times for a single WRITE, > for XFS it is incremented for each dirty transaction, which could > happen many times during a single write: > > (1) c/mtime update > (2) suid/sgid bit removal > (3) block allocation (could be multiple transactions) > > > So I guess we really should move to NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR > instead. Agreed. Just out of curiosity, though, why does XFS update i_version on every block allocation? For NFSv4 compatibility, it really should suffice for it to just do the update once in the above case. Did Lustre have more stringent requirements? -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- 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
