Summary

  • NFSv4.1 lets a client declare that its lock reclaims are complete. That declaration closes its remaining recovery claims within the relevant scope; it does not end other clients' opportunities.
  • A server may still refuse that client's new lock requests during grace. Safe admission depends on possible later reclaims, the lease boundary and recovery information retained across failure.
  • A partition followed by a restart can make an obsolete claim look harmless. The server needs enough persistent history to detect known hazards or must reject reclaims conservatively.

Two clients, one restart

Consider two clients that held locks before a storage server failed. The server restarts without the old lock state. One client reconnects promptly and restores its opens and byte-range locks. The other is still unreachable. From the first client's perspective, recovery is finished. From the server's perspective, a participant whose old claims might conflict with new work is still missing.

This is an illustrative protocol situation, not a reported outage. Its importance is the disagreement over what “finished” covers. The fast client has useful information about itself. It has no information that entitles it to waive the absent client's recovery opportunity.

NFSv4.1 makes that distinction explicit. The RFC 8881 specification, particularly sections 8.4, 9.11 and 18.51, separates a client's completion of reclaim from the server's management of the grace period. A completed participant can still receive NFS4ERR_GRACE when requesting a new lock. That result need not mean its earlier completion failed.

Restoring a claim is different from making a new one

After lock-state loss, the server must give clients an opportunity to recover prior state without intervening conflicting grants. A request to restore an existing open uses OPEN with CLAIM_PREVIOUS. It identifies the target through the current filehandle, rather than opening a newly named path from a directory. A byte-range lock reclaim uses LOCK with its reclaim parameter set to true.

These are not privileged ways to obtain whatever state the client now wants. Reclaims remain subject to ordinary access controls and conflict checks. A client does not acquire permission to open a file merely by describing its request as recovery.

Nor does grace mean that every operation stops. Creating the necessary client identity and session remains part of recovery. New locks or I/O may proceed where the server has sufficient information to establish that they will not conflict with a subsequent reclaim. Where that safety cannot be established, waiting protects a claim that has not yet arrived. The absent request is precisely why an empty current lock table is insufficient evidence.

The declaration that gives something up

For global completion, the client sends RECLAIM_COMPLETE with rca_one_fs false. After creating a new client ID, it must send this declaration before requesting its first new lock, even if it has no old locks to recover. Omitting it is not equivalent to saying that recovery was unnecessary.

The declaration is consequential. Locks within its scope that the client has not reclaimed can no longer be reclaimed in that recovery episode, a later server instance or after the relevant transfer to another server. Finishing therefore includes the abandonment of remaining reclaim eligibility. It is not just a progress notification that can be revised whenever a delayed piece of client state turns up.

That gives the server a usable boundary. It no longer has to reserve recovery space for additional old claims from that completed client. But other clients may still hold that possibility. The message reduces uncertainty about one participant; it cannot remove uncertainty about all of them.

The operation also has a per-filesystem form for migration. That form requires a current filehandle and is not a substitute for global completion after a new client ID. On a filesystem that is not in the relevant migration situation, the specified response can be success with the operation otherwise ignored. This article concerns server-restart recovery, not migration procedures.

Why the server may keep the barrier down

A server that has retained a stable record of the clients that might have held locks can use their completions to determine when everyone relevant has finished. That allows grace to end earlier than a blind wait would require. The record is valuable because it defines who must be accounted for, not because it contains a ceremonial count of successful responses.

The server can also reach the end of grace before every client has completed. That is not an unlimited discretion to cut off slow recovery immediately. Section 8.4.2.1 sets lease-related constraints: it says grace should not end before the lease period and, when discussing a changed lease value, requires the grace interval to be at least the previous instance's lease period. The specification does not supply a universal number of seconds for every installation.

There are therefore two separate boundaries to observe: when this client has finished reclaiming and when the server can safely admit the requested new work. A team measuring only the first can interpret a legitimate wait as a broken recovery. A team measuring only the second can miss a client that never completed its own protocol obligation.

A free lock can still have a dangerous history

The harder problem is not a slow client. It is a client whose memory of ownership survived a period in which that ownership did not.

RFC 8881 describes a sequence in which a partition prevents a client from renewing its lease. The lease expires and the server releases its lock. Another client acquires a conflicting lock, uses it and releases it. The server then restarts. When the partition heals, the first client tries to reclaim its old lock during grace.

At that instant no conflicting lock need remain. Nevertheless, granting the reclaim can be wrong: another participant may have changed the protected object while the first client's protection was absent. Present availability cannot establish uninterrupted prior ownership.

A second example adds another restart. A client misses part of the first grace period; new work takes place; the server restarts again; the client returns during the next grace period. A fresh recovery window must not erase the significance of the missed one.

These histories explain the specification's persistent-record requirement. A server must either reject all reclaims with NFS4ERR_NO_GRACE or retain sufficient stable information to detect all known restart-related edge conditions. The specification permits conservative rejection where more complete knowledge would have allowed recovery. If the recovery information is irrecoverably damaged, affected claims must be refused.

It offers a minimal client-record example, including client identity and indications of unacknowledged revocation or incomplete prior reclaim. That is an example, not a mandated database schema. More detailed records can support less severe rejection. Less retained information makes a promise of generous recovery harder to justify.

Refusal does not choose the application's future

A denied reclaim is not an instruction to carry on as though the lock had never been interrupted. RFC 8881 leaves the client's handling of NFS4ERR_NO_GRACE dependent on its operating environment. Examining a file's change attribute and attempting ordinary new opens or locks is discussed as a possible approach under appropriate client semantics, not a universal continuation guarantee.

The application may need to learn that its coordination was lost. Successfully obtaining a new lock proves present acquisition, not that no other actor intervened. The recovery mechanism cannot retroactively protect work performed during the gap.

The official document record identifies RFC 8881 as the August 2020 Proposed Standard replacing RFC 5661. Its errata listing was checked for this article: verified corrections and reported proposals have different status. The retrieved listing contains no direct correction to the three core sections used here. That is not a claim that the whole specification is defect-free or that current products behave identically.

Lu Heng's Note 32 on the agency problem supplies an editorial question about control and exposure: who decides, and who bears the consequence? His Note 36 on reality rather than advocacy counsels against replacing that inquiry with heroes and villains. Here the protocol supplies the technical facts. The incentive analysis is an interpretation, not evidence of any operator's motives.