Re: [nfsv4] I-D Action: draft-ietf-nfsv4-layoutwcc-01.txt

[Rick Macklem <[e-mail]>]

If Tom commented w.r.t. the use of LAYOUTCOMMIT for this,
I missed it.

Here are some snippets from RFC8881 Sec. 18.42 plus comments:

   The LAYOUTCOMMIT operation indicates that the client has completed
   writes using a layout obtained by a previous LAYOUTGET.  The client
   may have only written a subset of the data range it previously
   requested.  LAYOUTCOMMIT allows it to commit or discard provisionally
   allocated space and to update the server with a new end-of-file.
Note that the arguments loca_last_write_offset, loca_time_modify and
loca_layoutupdate can be used by the client to inform the MDS about
file changes due to writing to the DS.

   If the loca_reclaim field is set to TRUE, this indicates that the
   client is attempting to commit changes to a layout after the restart
   of the metadata server during the metadata server's recovery grace
   period (see Section 12.7.4).  This type of request may be necessary
   when the client has uncommitted writes to provisionally allocated
   byte-ranges of a file that were sent to the storage devices before
   the restart of the metadata server.
This explains how LayoutCommit can be used after an MDS reboot
to update the MDS w.r.t. writes done to the DS.

   The loca_last_write_offset field specifies the offset of the last
   byte written by the client previous to the LAYOUTCOMMIT.  Note that
   this value is never equal to the file's size (at most it is one byte
   less than the file's size) and MUST be less than or equal to
   NFS4_MAXFILEOFF.  Also, loca_last_write_offset MUST overlap the range
   described by loca_offset and loca_length.  The metadata server may
   use this information to determine whether the file's size needs to be
   updated.  If the metadata server updates the file's size as the
   result of the LAYOUTCOMMIT operation, it must return the new size
   (locr_newsize.ns_size) as part of the results.

   The loca_time_modify field allows the client to suggest a
   modification time it would like the metadata server to set.  The
   metadata server may use the suggestion or it may use the time of the
   LAYOUTCOMMIT operation to set the modification time.  If the metadata
   server uses the client-provided modification time, it should ensure
   that time does not flow backwards.  If the client wants to force the
   metadata server to set an exact time, the client should use a SETATTR
   operation in a COMPOUND right after LAYOUTCOMMIT.  See Section 12.5.4
   for more details.  If the client desires the resultant modification
   time, it should construct the COMPOUND so that a GETATTR follows the
   LAYOUTCOMMIT.
Here are details on how loca_last_write_offset and loca_time_modify
are used to update the MDS.

Although the Flex Files layout does not define any loca_layout_update,
it seems that this could be added more easily than new NFSv4.2 operations
if additional client->MDS information is deemed necessary.

Now, I do agree that:
   The LAYOUTCOMMIT operation commits changes in the layout represented
   by the current filehandle, client ID (derived from the session ID in
   the preceding SEQUENCE operation), byte-range, and stateid.
"commits changes in the layout" is kinda weird and does not clarify when
LayoutCommit should be done by a client. I think this should be clarified,
at least for Flex File Layout, as whenever the client has completed a series
of writes to DS(s) using the layout and expects the MDS to return
up-to-date Getattr information for the file to clients.

With the above clarification (or whatever works for you), I do not see why
new operations are needed?

rick

On Thu, Mar 30, 2023 at 5:57 PM <[e-mail]> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Network File System
> Version 4 (NFSV4) WG of the IETF.
>
>    Title           : Add LAYOUT_WCC to NFSv4.2's Flex File Layout Type
>    Authors         : Thomas Haynes
>                      Trond Myklebust
>    Filename        : draft-ietf-nfsv4-layoutwcc-01.txt
>    Pages           : 11
>    Date            : 2023-03-30
>
> 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 RFC8435 to
>    allow the client to update the metadata server to changes on the data
>    server.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-layoutwcc/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-nfsv4-layoutwcc-01.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-nfsv4-layoutwcc-01
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4