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

Rick Macklem <> Mon, 10 April 2023 23:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5BCEC151B0E; Mon, 10 Apr 2023 16:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WFZ5lRth0q65; Mon, 10 Apr 2023 16:10:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 070E3C151B0D; Mon, 10 Apr 2023 16:10:54 -0700 (PDT)
Received: by with SMTP id 60-20020a17090a09c200b0023fcc8ce113so8931343pjo.4; Mon, 10 Apr 2023 16:10:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; t=1681168254; x=1683760254; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=o8pxAzTgtm5OwfvvcqSoGvjFCacTJL4PSjrvgs5gZ2s=; b=BDeldRyjlVCgBBwIW5Zh5+gmhnftJQnnzGfovfY4XZfpFQmDrM6Q48BlUkDlqxm98Q cuYz3Z4h2/7KJSs6h8hnICv4otldiKERzKwQ4qjJ9iykccssOGn5hL2AZmTjHodzSIUV /H9PPBb5NsDaFaO5kFt9ev+K6rqmqRYBkQ0rxETkjdrIImntMiqtOega8ScTCX3agqiZ mHcmhw/7MjU7F5yok/0FQd7xdAN+792UYraACkTL30vRjTZDvXi6GhGmew+4Azee/X8j ugbbIuaElqlQtynxSqmBQkGIDxQHdkZu3Kvpge5R5OpAaMKAVmq6A7B5fcraaOlT0SoO ctjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; t=1681168254; x=1683760254; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=o8pxAzTgtm5OwfvvcqSoGvjFCacTJL4PSjrvgs5gZ2s=; b=oSicZhXBAMdQ9qARwtBstMecdueZXwyyj+c9/m+izbE3GJixx1bTbVubqLhcedhyg8 I3N+nPfo2FRWkgmUE22ehD1TVJEkL6f7nxGmRxqGZg/EOmLM5PlW55Salz1fMnD+zUq7 krOUsFGnwJsLP5S+pQTdQDALpF1pDXwQUi/rpJ9j8EhaZ5m62JK2m2ccN/pY9XhVdxqF 8NCx9vLNTTmbgd7ZmKxO397V+a7uEOsMT/1kytq+se0oEGw6SCvOk0HpGzID9lG6Ac/Q H3OLDPH2jZUor9PMvR7erxc2cXa3vPlLN4mTW0zxpItUDduaOYihZeWVrtA8J3/TAcq+ fOxA==
X-Gm-Message-State: AAQBX9dSXDaDggmbANJIkAjqxX/KScSxZdeHDqy4meXLX6/Ep0UIa5IL TgeEHpV8I7pTOUdOy1zd0GYoHrwAKFX/BwlabbiLZGVB7qJt
X-Google-Smtp-Source: AKy350avrICZZDqKpT5GL+xO9CPkfSD3aq54lslD0pCxZHUn1/b1of2ETP5qetdUTK6QmJxuPN9qjaiokiB/F6o0ALE=
X-Received: by 2002:a17:90a:2ecc:b0:23f:14c9:a606 with SMTP id h12-20020a17090a2ecc00b0023f14c9a606mr3149219pjs.6.1681168253822; Mon, 10 Apr 2023 16:10:53 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Rick Macklem <>
Date: Mon, 10 Apr 2023 16:10:44 -0700
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-layoutwcc-01.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Apr 2023 23:10:58 -0000

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
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?


On Thu, Mar 30, 2023 at 5:57 PM <> 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:
> There is also an HTML version available at:
> A diff from the previous version is available at:
> Internet-Drafts are also available by rsync at
> _______________________________________________
> nfsv4 mailing list