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

[Tom Haynes <[e-mail]>]

> On Jul 16, 2018, at 4:51 AM, David Noveck <[e-mail]> wrote:
> 
> > > - Those references to "microversion" should all be "minor version",
> > >  shouldn't they?
> 
> > I’ll check, but I think I mean microversion. 
> 
> Perhaps, but I'm not sure what "microversion" means.


I’ll create a draft. :-)

Minor version it is!

> 
> 
> On Sun, Jul 15, 2018 at 7:15 PM, Tom Haynes <[e-mail] <mailto:[e-mail]>> wrote:
> Hi Mike,
> 
> Thanks for the review!
> 
> Responses inline.
> 
> > On Jul 11, 2018, at 3:30 PM, Mike Kupfer <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > 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.
> 
> 
> Yes.
> 
> 
> > 
> > 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).
> 
> 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
> > 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
> 
> Thanks
> 
> > - Page 5
> > - Those references to "microversion" should all be "minor version",
> >  shouldn't they?
> 
> I’ll check, but I think I mean microversion.
> 
> 
> > - documuent -> document
> > - Section Section -> Section
> > - Page 7
> > - negiotiate -> negotiate
> > - Page 8
> > - prequisite -> prerequisite
> > - Section 4.1: "With a server" -> "When a server"
> > 
> > regards,
> > mike
> > 
> > _______________________________________________
> > nfsv4 mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
>