Subject: [nfsv4] durability of the change attribute?

From: Christoph Hellwig <[email-masked]>
Date: Sat, 8 Nov 2014 08:36:28 +0100

Section 18.32. of RFC5661 specified the DATA_SYNC4 stable value
as:

"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."

Which fits the classic Unix definition of O_DSYNC and fdatasync (and don't
bother to look that up in the Posix spec, it's so generic and obfuscated to
entirely hide the intent), which basically boils down to the size update
and block/extent map need to be committed, if a inode is only dirty
for time stamp updates it needs to written out.

For NFSv3, where this language originates from this allows to implement
the DATA_SYNC4 using fdatasync / O_DSYNC.  For NFSv4 things are getting
a bit more complicated as we now have to deal with the change attribute,
which doesn't fall into the classic timestamp categories as it hasn't
been around before NFSv4.  Given that it's mostly used for cache validation
it seems sensible to not force it out, but I'd really like to have
an errata on the spec that defines the durability requirements for the
change attribute (and the timestamps while we're at it).