RFC Errata

Errata Search

Source of RFC  
Summary Table Full Records

RFC 5661, "Network File System (NFS) Version 4 Minor Version 1 Protocol", January 2010

Note: This RFC has been obsoleted by RFC 8881

Source of RFC: nfsv4 (tsv)

Errata ID: 4119
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Christoph Hellwig
Date Reported: 2014-09-17
Held for Document Update by: Magnus Westerlund
Date Held: 2019-10-25

Section 12.2.10 says:

A device ID lives as long as there is a layout referring to the
device ID.  If there are no layouts referring to the device ID, the
server is free to delete the device ID any time.

It should say:

A device ID is established by referencing it in the result of a
GETDEVICELIST or LAYOUTGET operation and can be deleted by the server
as soon as there are no layouts referring to the device ID.

If the client requested notifications for device ID mappings, the
server SHOULD send CB_NOTIFY_DEVICEID notifications for device ID
deletions or changes to the device-ID-to-device-address mappings to any
client which has used the device-ID in question at least once,
irrespective of whether the client has any layouts currently referring
to it. If the server does not support or the client does not request
notifications for device ID mappings, the client SHOULD periodically
retired unused device IDs.

Given that GETDEVICELIST does not support requesting notifications a
server that implements GETDEVICELIST MUST not not advertise support
for NOTIFY_DEVICEID4_CHANGE notification in GETDEVICEINFO, and client
NOTIFY_DEVICEID4_DELETE notifications to work reliably.


The lifetime rules in RFC5661 are contradictory - both GETDEVICELIST and CB_NOTIFY_DEVICEID (NOTIFY4_DEVICEID_DELETE) operations imply that device IDs are valid even without layouts referring to them. Implementations rely on this fact by caching not referenced device IDs to avoid the huge setup costs, and thus require notifications to be sent for that case.

Report New Errata