Subject: [nfsv4] NFSv4.2 change_attr_type vs pNFS block/objects

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

I've been giving section 13.2.1. of NFSv4.2 another review and have
some questions or doubts regarding the interaction with pNFS block and object
layouts.

In both these cases writes go directly to the storage devices, and thus
the server can't update the change attribute for each write, but will
usually have to do this in LAYOUTCOMMIT.

There doesn't seem to be a change_attr type that can catch this easily.
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS seems close, but the wording
for it doesn't match, for one it uses the data server term that doesn't
apply to most pNFS layouts, and second the language that the number
of increments doesn't match the number of writes seems to disregard
the possibility that writes themselves never update the counter.

I propose to either change the language for
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS, or add a new
NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_LAYOUTCOMMIT with the following
language:

"The change attribute value MUST be incremented by one unit for every atomic
 change to the file attributes or directory contents, and any successful WRITE
 or LAYOUTCOMMIT operation."

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 10 Nov 2014 12:37:55 -0500

Hi Christoph,

>  or LAYOUTCOMMIT operation."

It was certainly my intention when i wrote the original personal draft
that blocks and objects should be able to defer the change attribute
update to layoutcommit time.
IIRC, I deliberately did not specify that how the change attribute
should be updated when doing pNFS, since there might be different
schemes, depending on how tightly the MDS and the DS are coupled. An
object based system might, for instance, poll the object every n
seconds while waiting for the final layoutcommit that says the client
is done writing...

Cheers
  Trond