RFC 3530, "Network File System (NFS) version 4 Protocol", April 2003
Note: This RFC has been obsoleted by RFC 7530Source of RFC: nfsv4 (tsv)
See Also: RFC 3530 w/ inline errata
Errata ID: 2637
Publication Format(s) : TEXT
Reported By: Marcel Telka
Date Reported: 2010-11-19
Verifier Name: Lars Eggert
Date Verified: 2011-03-07
Section 14.2.18. says:
Instead, to avoid unbounded memory use, the server needs to implement a strategy for disposing of open_owner4s that have no current lock, open, or delegation state for any files and have not been used recently.
It should say:
Instead, to avoid unbounded memory use, the server needs to implement a strategy for disposing of open_owner4s that have no current open state for any files and have not been used recently.
A lock can be held on already opened files only. This means that every lock state can exist only in case the accompanied open state is already there.
So if there is a lock state held by server then there must be an open state for the file too. This means that we do not need to mention the "current lock state" in the RFC's sentence above.
Next, the delegation state is allocated only in case the delegation is granted by server to a client for a file. The delegation state is related to file and client. It is not related/tied to openowner. This means that it is not possible to test whether an openowner have any delegation states. Delegation states are simply not related to the openowner.
It is easily possible to have a client with some delegation granted with no valid openowner held by a server.