Re: [nfsv4] New Version Notification for draft-haynes-nfsv4-layoutwcc-00.txt

["Mkrtchyan, Tigran" <[e-mail]>]

----- Original Message -----
> From: "Thomas Haynes" <[e-mail]>
> To: "Dave Noveck" <[e-mail]>
> Cc: "Tigran Mkrtchyan" <[e-mail]>, "NFSv4" <[e-mail]>
> Sent: Monday, 20 February, 2023 16:43:13
> Subject: Re: [nfsv4] New Version Notification for draft-haynes-nfsv4-layoutwcc-00.txt

> On Feb 20, 2023, at 12:15 AM, David Noveck <[e-mail]> wrote:
> 
> 
> 
> On Sun, Feb 19, 2023, 6:53 PM
> [e-mail]<mailto:[e-mail]>
> <[e-mail]<mailto:[e-mail]>> wrote:
> Hi Tom,
> I like the idea. It looks like that the draft is limited only to NFSv3 based
> flexfiles layouts.
> 
> That was my impression as well.
> 
> 
> Neither nfsv41_files nor flexfiles layouts allow GETATTR requests to be sent to
> data servers.
> 
> In retrospect, that was probably a design mistake in pNFS, but it's probably too
> late to address that now.
> 
> 
> If we were to allow it, I would limit it to be after a COMMIT, READ, or a WRITE.
> I would not allow a compound like:
> 
> SEQUENCE
> PUTFH
> GETATTR
> 
> And simply such that we can mimic WCC, although it would now be SCC,
> 
> 
> 
> Thus only in responses to READ or WRITE over v3 clients will get the wcc
> information.
> 
> In nfsv4_files, the client could get them from the mds, with the understanding
> that the implementation would propagate this information from ds to the mds
> using the control protocol.
> 
> However the draft position itself to be more generic.
> 
> It does but that is probably the result of text written when this was part of
> delstid.  Most of delstid concerned general v4 extensions and the text might
> not have been appropriately adjusted to reflect the split.
> 
> 
> 
> No, it was a pure mental block on my end.
> 
> 
> 
> Do I miss something?
> 
> There is something missing but I feel it is the authors' responsibility to make
> this issue clear.
> 
> 
> Yes. Lets see if the new draft clears it up.


Looking forward to reading the updated draft.

Thanks a lot for your efforts! Best regards,
   Tigran.

> 
> 
> 
> Tom has requested we adopt this draft as a working group document.  Let's do
> that ASAP.  To make further progress, we need to address the scope issue you
> pointed out and the relationship of this document to the flexfiles layout
> document.
> 
> Best regards,
> - Tigran
> -------- Original message --------
> From: Thomas Haynes
> Date: Thu, Feb 16, 2023, 00:02
> To: NFSv4
> Subject: [nfsv4] Fwd: New Version Notification for
> draft-haynes-nfsv4-layoutwcc-00.txt
> 
> 
> Hi,
> 
> As part of the review of delstid, it was suggested that I pull this part out of
> that document and create a new draft.
> 
> This then is that result.
> 
> I ask the working group to adopt this draft was a WG one. This is work that had
> previously been accepted as part of the delstid one.
> 
> Thanks,
> Tom
> 
> Begin forwarded message:
> 
> From: [e-mail]<mailto:[e-mail]>
> Subject: New Version Notification for draft-haynes-nfsv4-layoutwcc-00.txt
> Date: February 15, 2023 at 2:58:00 PM PST
> To: "Thomas Haynes" <[e-mail]<mailto:[e-mail]>>,
> "Trond Myklebust" <[e-mail]<mailto:[e-mail]>>
> 
> 
> A new version of I-D, draft-haynes-nfsv4-layoutwcc-00.txt
> has been successfully submitted by Thomas Haynes and posted to the
> IETF repository.
> 
> Name: draft-haynes-nfsv4-layoutwcc
> Revision: 00
> Title: Add LAYOUT_WCC to NFSv4.2
> Document date: 2023-02-15
> Group: Individual Submission
> Pages: 9
> URL:
> https://www.ietf.org/archive/id/draft-haynes-nfsv4-layoutwcc-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-haynes-nfsv4-layoutwcc/
> Html:
> https://www.ietf.org/archive/id/draft-haynes-nfsv4-layoutwcc-00.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-haynes-nfsv4-layoutwcc
> 
> 
> Abstract:
>  The Parallel Network File System (pNFS) allows for a file's metadata
>  (MDS) and data (DS) to be on different servers.  It does not provide
>  a mechanism for the data server to update the metadata server of
>  changes to the data part of the file.  The client has knowledge of
>  such updates, but lacks the ability to update the metadata server.
>  This document presents several refinements to both RFC8881 and
>  RFC8434 to allow the client to update the metadata server to changes
>  on the data server.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/nfsv4
> _______________________________________________
> nfsv4 mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/nfsv4