Subject: Re: [nfsv4] [Technical Errata Reported] RFC5661 (3208)

From: Martin Stiemerling <[email-masked]>
Date: Wed, 16 Dec 2015 23:03:48 +0100

Hi,

Following this up after a very long time:

I will approve the errata without the part of Section 18.43.3.

Please submit a new errata for Section 18.43.3 with the text below.

Thanks,

   Martin

Am 09.05.12 um 19:43 schrieb Marc Eshel:
>
> Can we update the Errata with the following?
> Thanks, Marc.
>
>
> 18.43.3 that should go into v4.1 errata.
> Marc.
>
> section 18.43.3 say:
>
> The logr_return_on_close result field is a directive to return the layout
> before closing the file.  When the metadata server sets this  return value
> to TRUE, it MUST be prepared to recall the layout in the case in which the
> client fails to return the layout before close.  For the metadata server
> that knows a layout must be returned before a close of the file, this
> return value can be used to communicate the desired behavior to the client
> and thus remove one extra step from the client's and metadata server's
> interaction.
>
> it should say:
>
> The logr_return_on_close result field is a directive to return or forget
> the layout before closing the file . When the metadata server sets this
> return value to TRUE, the client MUST NOT use the layout and the respective
> layout stateid after sending the last CLOSE of that file. Any outstanding
> COMMIT to the data servers or LAYOUTCOMMIT to the metadata server MUST be
> sent prior to closing the file. This return value is used to communicate to
> the client that any layout or segment of a layout that were given with
> logr_return_on_close set to TRUE will result in the server invalidating all
> layouts of layouttype4 of loga_layout_type for the file after it was
> closed.
> Once the server returns logr_return_on_close set to TRUE to a client for a
> given file it MUST set logr_return_on_close to TRUE for all subsequent
> layouts or segments of layoutype4 of the respective loga_layout_type for
> that file and client until that file is closed.
>
> Notes:
>
> This directive will remove one or more extra steps from the client's and
> metadata server's interaction.
>
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 16 Dec 2015 23:08:49 +0100

and apparently Section 18.43.3. is also discussed in this errata:

https://www.rfc-editor.org/verify_errata_select.php?eid=3901

It would be good to get an errata that has been verified by the WG/authors.

Thanks,

   Martin

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 16 Dec 2015 17:51:38 -0500

> It would be good to get an errata that has been verified by the WG/authors.

 Given that we are allowed to use a delegation stateid in an initial
LAYOUTGET, we either need well defined semantics for how
return-on-close is supposed to behave in that situation.

The Linux client is already coded to expect return-on-close to persist
until it also returns the delegation.