[nfsv4] Gunter Van de Velde's Discuss on draft-ietf-nfsv4-layoutwcc-05: (with DISCUSS and COMMENT)

[Gunter Van de Velde via Datatracker <[e-mail]>]

Gunter Van de Velde has entered the following ballot position for
draft-ietf-nfsv4-layoutwcc-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-layoutwcc/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# Gunter Van de Velde, RTG AD, comments for draft-ietf-nfsv4-layoutwcc-05

# the referenced line numbers are derived from the idnits tool:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-nfsv4-layoutwcc-05.txt

# Many thanks for this document. I am not very NFS aware, so my review is only
high level and editorial. I do however have a single easy to resolve DISCUSS.

# I found the text at times not trivial to read due to strange language
constructs. In some instances i proposed an editorial rewrite you could
consider.

#DISCUSS
#=======

# In the IANA section is written that there is no action required, but line 244
and 245 seem to indicate that there is a code point allocated for lowa_type.
Maybe i got confused and misunderstood the text, or maybe the needs to describe
the intent more accurate for NFS unware people as myself?

244        The lowa_type is defined to be a value from the IANA registry for
245        'pNFS Layout Types Registry'.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

#DETAILED COMMENTS
#=================

10      Abstract
11
12         The Parallel Network File System (pNFS) Flexible File Layout allows
13         for a file's metadata (MDS) and data (DS) to be on different servers.
14         It does not provide a mechanism for the data server to update the
15         metadata server to changes to the data part of the file.  The client
16         has knowledge of such updates, but lacks the ability to update the
17         metadata server.  This document presents a refinement to RFC8435 to
18         allow the client to update the metadata server to changes on the data
19         server.

GV> What about the following alternative abstract:

"
This document specifies extensions to the parallel Network File System (NFS)
version 4 (pNFS) for improving write cache consistency. These extensions
introduce mechanisms that ensure partial writes performed under a pNFS layout
remain coherent and correctly tracked. The solution addresses concurrency and
data integrity concerns that may arise when multiple clients write to the same
file through separate data servers. By defining additional interactions among
clients, metadata servers, and data servers, this specification enhances the
reliability of NFSv4 in parallel-access environments and ensures consistency
across diverse deployment scenarios. "

106        See Section 1.1 of [RFC8435] for a fuller set of definitions.

GV> Not sure that using the word "fuller" is appropriate. What about:

"
For a more comprehensive set of definitions, see Section 1.1 of [RFC 8435].
"

143        A layout type for pNFS enables the metadata server to tell the client
144        both the storage protocol and location of data to be used to
145        communicate with the storage devices.  The Flex Files Layout Type (in
146        [RFC8435]) details how NFSv3 data servers can be accessed.  The
147        client is only allowed to perform NFSv3 READ (see Section 3.3.6 of
148        [RFC1813]), WRITE (see Section 3.3.6 of [RFC1813]), and COMMIT (see
149        Section 3.3.21 of [RFC1813]) operations on the file handles provided
150        in the layout.  I.e., the client is only allowed to use NFSv3
151        operations which directly act on the data portion of the data file.

GV> I find the use of "to tell" odd in IETF text. What about the following
editorial suggestion:

"
A pNFS layout type enables the metadata server to inform the client of both the
storage protocol and the locations of the data that the client should use when
communicating with the storage devices. The Flex Files Layout Type, as
specified in [RFC 8435], describes how data servers using NFSv3 can be
accessed. The client is restricted to performing NFSv3 READ (Section 3.3.6 of
[RFC 1813]), WRITE (Section 3.3.6 of [RFC 1813]), and COMMIT (Section 3.3.21 of
[RFC 1813]) operations on the file handles provided in the layout. In other
words, the client may only use NFSv3 operations that act directly on the data
portion of the file. "

170        For example, the metadata server would issue a NFSv3 GETATTR to the
171        data server.  This query is most likely triggered in response to a
172        NFSv4 GETATTR issued by a client to the metadata server.  Not only
173        are these NFSv3 GETATTRs to the data server individually expensive,
174        the data server can become inundated by a storm of such requests.
175        NFSv3 solved a similar issue by having the READ and WRITE operations
176        employ a post-operation attribute to report the weak cache
177        consistency (WCC) data (See Section 2.6 of [RFC1813]).

GV> This reads odd to me. Are you trying to suggest the following

"
For example, the metadata server might issue an NFSv3 GETATTR operation to the
data server, which is typically triggered by a client’s NFSv4 GETATTR request
to the metadata server. In addition to the cost of each individual GETATTR
operation, the data server can be overwhelmed by a large volume of such
requests. NFSv3 addressed a similar challenge by including a post-operation
attribute in the READ and WRITE operations to report weak cache consistency
(WCC) data (see Section 2.6 of [RFC 1813]). "

179        Each NFSv3 operation corresponds to one round trip between the client
180        and server.  So a WRITE followed by a GETATTR would require two round
181        trips.  In that scenario, the attribute information retrieved is
182        considered to be strict server-client consistency.  For NFSv4, the
183        WRITE and GETATTR can be issued together inside a compound, which
184        only requires one round trip between the client and server.  And this
185        is also considered to be a strict server-client consistency.  In
186        essence, the NFSv4 READ and WRITE operations drop the post-operation
187        attributes, allowing the client to decide if it needs that
188        information.

GV> Proposal text:

"
Each NFSv3 operation entails a single round trip between the client and server.
Consequently, issuing a WRITE followed by a GETATTR would require two round
trips. In that situation, the retrieved attribute information is regarded as
strict server-client consistency. By contrast, NFSv4 enables a WRITE and
GETATTR to be combined within a compound operation, which requires only one
round trip. This combined approach is likewise considered strict server-client
consistency. Essentially, NFSv4 READ and WRITE operations omit post-operation
attributes, allowing the client to determine whether it requires that
information. "

205        In this document, we present a new NFSv4.2 operation called
206        LAYOUT_WCC, which allows the client to update the metadata server
207        with information from the data server.  The client is responsible for
208        taking the NFSv3 WCC information (which is returned by the 3
209        operations it is allowed to use) and pass that back to the metadata
210        server in the NFSv4.2 attributes.  The metadata server MAY then avoid
211        costly NFSv3 GETATTR calls to the data servers.  As this is a weak
212        model, the metadata server MAY make such calls anyway in order to
213        strengthen the model.

GV> proposal text:

"
This document introduces a new NFSv4.2 operation, LAYOUT_WCC, which enables the
client to provide the metadata server with information obtained from the data
server. The client is responsible for gathering the NFSv3 WCC data, returned by
the three permissible NFSv3 operations, and conveying it back to the metadata
server as part of NFSv4.2 attributes. The metadata server MAY therefore avoid
issuing costly NFSv3 GETATTR calls to the data servers. Because this approach
relies on a weak model, the metadata server MAY still perform these calls if it
chooses to strengthen the model. "

239     3.3.  DESCRIPTION
240
241        The current filehandle and the lowa_stateid identifies the particular
242        layout for the LAYOUT_WCC operation.  The lowa_type indicates how to
243        unpack the layout type specific payload inside the lowa_body field.
244        The lowa_type is defined to be a value from the IANA registry for
245        'pNFS Layout Types Registry'.
246
247        The lowa_body will contain the data file attributes.  The client will
248        be responsible for mapping the NFSv3 post-operation attributes to
249        those in a fattr4.  Just as the post-operation attributes may be
250        ignored by the client, the server may ignore the attributes inside
251        the LAYOUT_WCC.  But the server can also use those attributes to
252        avoid querying the data server for the data file attributes.  Note
253        that as these attributes are optional and there is nothing the client
254        can do if the server ignores one, there is no need to return a
255        bitmap4 of which attributes were accepted in the result of the
256        LAYOUT_WCC.

GV> Alternative proposal text:

"
The current filehandle and the lowa_stateid identify the specific layout for
the LAYOUT_WCC operation. The lowa_type indicates how to interpret the
layout-type-specific payload contained in the lowa_body field. This lowa_type
is defined as a value (TBD#1) from the IANA registry for 'pNFS Layout Types'.

The lowa_body contains the data file attributes. The client is responsible for
mapping NFSv3 post-operation attributes to the fattr4 representation. Similar
to the behavior of post-operation attributes, the client may ignore these
attributes, and the server may also choose to ignore any attributes included in
LAYOUT_WCC. However, the server can use these attributes to avoid querying the
data server for data file attributes. Because these attributes are optional and
the client has no recourse if the server opts to disregard them, there is no
requirement to return a bitmap4 indicating which attributes have been accepted
in the LAYOUT_WCC result. "

458     6.  IANA Considerations
459
460        This section is to be removed before publishing as an RFC.
461
462        There are no IANA considerations for this document.

GV> Is this correct? Section 3 at line 244 & 245 i read:

   The lowa_type is defined to be a value from the IANA registry for
   'pNFS Layout Types Registry'.

Does this not indicate that there is a value assigned by IANA?

Many thanks again for this document,

Kind Regards,
Gunter Van de Velde,
RTG AD