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

Here are a few generic comments...
As it stands, I could not implement this in a way that I would think
would be useful.

- There is no indication when the client should issue this operation to
  the MDS. I'd suggest something like "whenever the client expects attributes
  related to writing is up-to-date for a Getattr against the MDS" or something
  like that.
  --> As a client implementor, I need to know when to do this..

Which attributes? It doesn't seem to get specific about what attributes.
I'd suggest a specific list. Possibly:
Size
Change
TimeModify
SpaceUsed
and maybe TimeAccess?

Change is going to be problematic for NFSv3 DSs.
Maybe a mechanism similar to what is defined for handling
Change when a client holds a Write delegation can be used?

When I did the pNFS flexfile layout client, I did a LayoutCommit
whenever the client needs up-to-date attrbute values, because I
thought that was what LayoutCommit would be useful for.
--> If the client does this, the pNFS flexfiles layout server only needs
      to get up-to-date attributes from the DS at that point in time and
      can cache them in the MDS otherwise, unless there are Getattr
      requests from client(s) that do not do pNFS, such as NFSv3/v4.0
      clients.
--> I discovered that the Linux client does not do LayoutCommit for
      some cases where it expects the above attributes to be up-to-date,
      so I was forced to query the DS whenever the MDS receives a
      Getattr and any RW layout for the file has been given out.
      (The description of when to do LayoutCommit is vague in the RFCs.
        I recall the Linux client doesn't do a LayoutCommit unless it needs
        to also do a Commit to the DS.)

My point is, this situation can be improved if there is a well defined
"if the client expects up-to-date attributes, it must do this".

In general, for this to be useful for me to implement (client and server),
I need more specifics w.r.t. what attributes, when the Layout_wcc must
be done.

rick

> ----- Original Message -----
> > From: "Thomas Haynes" <loghyr@hammerspace.com>
> > To: "NFSv4" <nfsv4@ietf.org>
> > Sent: Monday, 20 February, 2023 16:48:45
> > Subject: [nfsv4] Fwd: New Version Notification for draft-haynes-nfsv4-layoutwcc-01.txt
>
> > This version addresses the issue that the draft is NFSv3 Flex Files only.
> >
> > Thanks,
> > Tom
> >
> > Begin forwarded message:
> >
> > From: internet-drafts@ietf.org
> > Subject: New Version Notification for draft-haynes-nfsv4-layoutwcc-01.txt
> > Date: February 20, 2023 at 7:46:54 AM PST
> > To: "Thomas Haynes" <loghyr@hammerspace.com>, "Trond Myklebust"
> > <trondmy@hammerspace.com>
> >
> >
> > A new version of I-D, draft-haynes-nfsv4-layoutwcc-01.txt
> > has been successfully submitted by Thomas Haynes and posted to the
> > IETF repository.
> >
> > Name: draft-haynes-nfsv4-layoutwcc
> > Revision: 01
> > Title: Add LAYOUT_WCC to NFSv4.2
> > Document date: 2023-02-20
> > Group: Individual Submission
> > Pages: 9
> > URL:
> > https://www.ietf.org/archive/id/draft-haynes-nfsv4-layoutwcc-01.txt
> > Status:         https://datatracker.ietf.org/doc/draft-haynes-nfsv4-layoutwcc/
> > Html:
> > https://www.ietf.org/archive/id/draft-haynes-nfsv4-layoutwcc-01.html
> > Htmlized:
> > https://datatracker.ietf.org/doc/html/draft-haynes-nfsv4-layoutwcc
> > Diff:
> > https://author-tools.ietf.org/iddiff?url2=draft-haynes-nfsv4-layoutwcc-01
> >
> > Abstract:
> >  The Parallel Network File System (pNFS) Flexible File Layout 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 a refinement to RFC8434 to
> >  allow the client to update the metadata server to changes on the data
> >  server.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
> >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@ietf.org
> > https://www.ietf.org/mailman/listinfo/nfsv4
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4