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

From: Mike Kupfer <[email-masked]>
Date: Wed, 11 Jul 2018 15:30:08 -0700

Here's my feedback on draft-haynes-nfsv4-delstid-00.  I've omitted a
couple comments that were already covered by Dave Noveck.  Apologies
for not getting this written up earlier.

* Comments on delegated timestamps

Another use case for delegated timestamps would be when the client has
a lot of dirty data for the file and an application asks for the
file's mtime.  My understanding is that the Linux client delays the
stat() call until the dirty data is written back.  If the client can
specify the mtime, then there's no need to wait for the writeback to
finish.

The current proposal disallows setting the timestamp to an earlier
time, and it disallows setting the timestamp to a time in the future.
Are those restrictions really necessary?  If yes, then the spec should
discuss how the client can make such changes (e.g., in response to a
user specifying a time via the "touch" command).  (And don't NetApp
and EMC have some scheme where a file can be made immutable and
unremovable by a series of steps that include changing the access
time?)

When the spec talks about the server accepting the time values from
the client, I assume that the server is allowed to lose precision, as
per Section 2.2.1 of RFC 7530.

* Editorial nits

- Page 1
  - serveral -> several
  - opeing -> opening
- Page 2
  - semnatics -> semantics
- Page 5
  - Those references to "microversion" should all be "minor version",
    shouldn't they?
  - documuent -> document
  - Section Section -> Section
- Page 7
  - negiotiate -> negotiate
- Page 8
  - prequisite -> prerequisite
  - Section 4.1: "With a server" -> "When a server"

regards,
mike

---

From: Tom Haynes <[email-masked]>
Date: Wed, 11 Jul 2018 16:14:31 -0700

That reminds me I have Dave and Chuck’s reviews to go through as well.

My plan is to address these on the way to Montreal and publish a new draft once the gates open up.

Thanks to everyone for the reviews.

> On Jul 11, 2018, at 3:30 PM, Mike Kupfer <[email-masked]> wrote:
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Tom Haynes <[email-masked]>
Date: Sun, 15 Jul 2018 16:15:57 -0700

Hi Mike,

Thanks for the review!

Responses inline.

> specify the mtime, then there's no need to wait for the writeback to

Yes.

> user specifying a time via the "touch" command).

The setting of the timestamp for the delegation caching is different
than the setting of the timestamp from touch. The first is an operation
that the proxy is performing to update the data file properties and the
second is an operation being performed on the meta data properties.

The MDS would have to use a CB_GETATTR to get those times
from the proxy server when it saw the explicit SETATTR. It would
want to make sure the times it had recorded for the data file were
updated to match the times that were being set.

If we ignore time proxying, then a model for determining when
the times change would be for the MDS to record the data file
time attributes whenever it hands out a layout to a client. Then,
whenever the MDS does a GETATTR to the data file (in response
to a GETATTR from the client looking for one of times, size, or
bytes used), then it can use the difference of the data file
attributes to calculate a new mtime, atime, and ctime for the
metadata portion of the file.

Let me know how much of that you need to go into the document - I’m
probably too close to the problem/implementation details. 

> (And don't NetApp

Thanks

> - Those references to "microversion" should all be "minor version",

I’ll check, but I think I mean microversion.

---

From: David Noveck <[email-masked]>
Date: Mon, 16 Jul 2018 04:51:43 -0400

> I’ll check, but I think I mean microversion.

Perhaps, but I'm not sure what "microversion" means.

---

From: Tom Haynes <[email-masked]>
Date: Mon, 16 Jul 2018 10:49:14 -0400

> On Jul 16, 2018, at 4:51 AM, David Noveck <[email-masked]> wrote:
> 

I’ll create a draft. :-)

Minor version it is!

> 
> 
> On Sun, Jul 15, 2018 at 7:15 PM, Tom Haynes <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Mike,
> 
> Thanks for the review!
> 
> Responses inline.
> 
> > On Jul 11, 2018, at 3:30 PM, Mike Kupfer <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
>

---

From: Tom Haynes <[email-masked]>
Date: Mon, 16 Jul 2018 10:52:27 -0400

Hi Spencer and Beepy,

In the meeting today I asked for the delstid draft to be moved forward as a WG document.

There was no dissent (to be completely fair, nor consent either…)

Thanks,
Tom

---

From: Mike Kupfer <[email-masked]>
Date: Wed, 25 Jul 2018 17:49:07 -0700

> probably too close to the problem/implementation details.

Hmm.  Let's back up a moment.  I understand that you have a particular
use case for the extension.  How closely is the extension tied to that
use case?  If I just have a client and server, with no pNFS and no proxy
server, does the extension provide value?  I had thought yes, because it
gives the client explicit control over the modify and access times when
the delegation is returned.  But maybe in the simple case there's no
need for the extension, because the client could just do a SETATTR when
it returns the delegation?

mike

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 25 Jul 2018 19:48:56 -0700

> On Jul 25, 2018, at 5:49 PM, Mike Kupfer <[email-masked]> wrote:
> 
> 

Close, but 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.