Subject: Re: [nfsv4] draft-haynes-nfsv4-delstid-00 comments

From: Mike Kupfer <[email-masked]>
Date: Wed, 29 Aug 2018 18:10:12 -0700

(Sorry for the slow reply.)

Thomas Haynes wrote:

> there is a difference between setattr(mtime, atime) and
> setattr(delegated_mtime, delegated_atime).
> 
> In the first form, the ctime will be the time the server gets the
> setattr request and in the new form, it would be delegated_mtime.

Ah.  So the reason (or at least a reason) for putting bounds on 
delegated_mtime is so that the server ends up with a sane ctime?

That still leaves me wondering why there are bounds on delegated_atime,
though I suppose there's some value in having symmetry with
delegated_mtime.

A couple other technical points that I'm unclear on:

In the first paragraph of Page 8, I'd like to find some wording other
than "old times" or "original time".  Do you mean the current value of
the appropriate attribute (time_access or time_modify), or the value
that the attribute had when the delegation was granted?  (They need not
be the same, since the client could have changed the attribute's value
with a SETATTR.)

What should the server do if the client returns an out-of-bounds value
for FATTR4_TIME_DELEG_ACCESS or FATTR4_TIME_DELEG_MODIFY in a CB_GETATTR
reply?

mike

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 30 Aug 2018 09:41:30 -0400

Hi Mike,

> On Aug 29, 2018, at 21:10, Mike Kupfer <[email-masked]> wrote:
> 

It is to ensure that the timestamps don’t run amuck. We want to avoid situations where timestamps appear to regress if/when the server or another client needs to update them later.

Note that if the client wants to explicitly set a value for the mtime that is in the future, because the user called futimens()/utimensat() then it can still use the standard FATTR4_TIME_MODIFY_SET/FATTR4_TIME_ACCESS_SET to override the bounds.

> for FATTR4_TIME_DELEG_ACCESS or FATTR4_TIME_DELEG_MODIFY in a CB_GETATTR

In our prototype implementation, we’ve simply had the server truncate the timestamps to the value of “current time” if the client is attempting to set a value in the future. I suppose you could return an error, but how would the system then go about recovering?

Cheers
  Trond

---

From: Mike Kupfer <[email-masked]>
Date: Thu, 30 Aug 2018 13:53:45 -0700

Hi Trond!

> In our prototype implementation, we’ve simply had the server truncate
> the timestamps to the value of “current time” if the client is
> attempting to set a value in the future.

That makes sense.  And if the value is too old, I guess the server could
just ignore it (i.e., use whatever value it had previously for the
attribute).

mike