[nfsv4] [Technical Errata Reported] RFC7862 (9244)

rfc-editor@rfc-editor.org Tue, 27 October 2026 22:49 UTC

Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: rfc-editor@rfc-editor.org
To: loghyr@gmail.com, gorry@erg.abdn.ac.uk, spencerdawkins.ietf@gmail.com, spencer.shepler@gmail.com, mbishop@evequefou.be
Date: Tue, 27 Oct 2026 22:49:04 -0000
message-id: <179314134418.15.1059493668091857298@rfc-editor.org>
Message-ID-Hash: NA4ZA25TZKFPNCD7OPUYBQEGIFSGQLJI
CC: rfc-editor@rfc-editor.org, ben.coddington@hammerspace.com, nfsv4@ietf.org
Precedence: list
Subject: [nfsv4] [Technical Errata Reported] RFC7862 (9244)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/hBAcnAvXbveyAl3F39mKo0wPAik>

The following errata report has been submitted for RFC7862,
"Network File System (NFS) Version 4 Minor Version 2 Protocol"

--------------------------------------
You may review the report below and at:
https://errata.rfc-editor.org/eid9244/

--------------------------------------
Type: Technical
Reported by: Benjamin Coddington <ben.coddington@hammerspace.com>

Section 14.2.3 says:

Original Text
-------------
14.2.3.  MOTIVATION

   The GETDEVICELIST operation was introduced in [RFC5661] specifically
   to request a list of devices at file system mount time from block
   layout type servers.  However, the use of the GETDEVICELIST operation
   introduces a race condition versus notification about changes to pNFS
   device IDs as provided by CB_NOTIFY_DEVICEID.  Implementation
   experience with block layout servers has shown that there is no need
   for GETDEVICELIST.  Clients have to be able to request new devices
   using GETDEVICEINFO at any time in response to either a new deviceid
   in LAYOUTGET results or the CB_NOTIFY_DEVICEID callback operation.

14.2.4.  DESCRIPTION

   Clients and servers MUST NOT implement the GETDEVICELIST operation.

Corrected Text
--------------
14.2.3.  MOTIVATION

   The GETDEVICELIST operation was introduced in [RFC5661] specifically
   to request a list of devices at file system mount time from block
   layout type servers.  It is also useful to clients of layout types
   with many storage devices, which can use the list to establish
   connections to those devices before the first I/O.  Clients still
   have to be able to request new devices using GETDEVICEINFO at any
   time in response to either a new deviceid in LAYOUTGET results or
   the CB_NOTIFY_DEVICEID callback operation.

14.2.4.  DESCRIPTION

   GETDEVICELIST is OPTIONAL, and is as described in Section 18.41 of
   [RFC5661].  A GETDEVICELIST reply can race with CB_NOTIFY_DEVICEID
   in the same way a GETDEVICEINFO reply can, and the client handles
   it as described in Section 18.40.4 of [RFC5661].

Notes
-----
Section 14.2.3 says GETDEVICELIST introduces a race with
CB_NOTIFY_DEVICEID, but I can't find an ordering that breaks.

GETDEVICELIST returns only device IDs, so a CHANGE crossing its reply
has nothing to make stale.  Notifications are registered per device ID
by GETDEVICEINFO, and the client has no address for an ID until that
GETDEVICEINFO completes.  A DELETE crossing the reply is covered by
the "mark the device ID as deleted" rule in RFC 5661 Section 18.40.4,
which already names GETDEVICELIST, and device IDs are never reused.
If an ID is deleted between the list and GETDEVICEINFO, the client
just gets NFS4ERR_NOENT.

We'd like the operation back for flex files clients with many data
servers.  Those clients pay for connection setup (TCP, and
RPC-with-TLS) on the first I/O to each data server, and a device list
at mount lets them do that work up front.

I raised this on the nfsv4 list on 2026-10-22 and haven't had any
replies:
https://mailarchive.ietf.org/arch/msg/nfsv4/L1UyZH5PaZupkAGp2s6oJEfSo34/

Instructions:
-------------
This erratum is currently posted as "Reported". Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7862 (draft-ietf-nfsv4-minorversion2)
--------------------------------------
Title               : Network File System (NFS) Version 4 Minor Version 2 Protocol
Publication Date    : November 2016
Author(s)           : T. Haynes
Category            : Proposed Standard
Source              : nfsv4 (wit)
Stream              : IETF
Verifying Party     : IESG

[nfsv4] [Technical Errata Reported] RFC7862 (9244) rfc-editor