Re: [PATCH v1 1/3] nfsd: report NFSv4 grace state through Netlink

[Chuck Lever]

On Thu, Aug 27, 2026, at 12:51 AM, Prabhakar Pujeri wrote:
> On Tue, 2026-08-25 at 08:10 -0400, Jeff Layton wrote:
>> What's your interest in reporting this info?
>
> My interest is in making nfsd's operational state observable to
> monitoring and validation tooling without parsing nfsdfs.
>
> Concretely, I'm building a validation harness for NFS server
> restart and failover behaviour: bounce the server, drive reclaim from a
> set of clients, and check that state comes back the way it should. That
> kind of test has to know when the grace period has actually lifted
> before it can move on to the next phase. Polling
> /proc/fs/nfsd/v4_end_grace works, but it is a text interface, it only
> answers for nfsd's v4 lock manager, and new nfsd control and
> observability interfaces are going to the netlink family instead.
>
> So I would rather frame this as parity than as new information: grace
> state is already exported, this puts it on the interface that is
> replacing the one exporting it, and -- per your point below -- fixes
> the semantics on the way over.
>
>> Just because the v4 recovery is done does not mean that you will be
>> able to access files. The overall system grace period is a union of
>> both the NLM and v4 grace periods.
>>
>> This patch is reporting just the v4 one. If the goal is for the admin
>> to reliably tell when the grace period has been lifted, then this
>> won't tell us that.
>
> Agreed, and "has the grace period lifted" is the question I actually
> care about. I mirrored the semantics of /proc/fs/nfsd/v4_end_grace
> without stopping to ask whether those were the useful semantics to
> expose in a new interface. They aren't.
>
>> Maybe this should just return the result of locks_in_grace() instead?
>>
>> Or, do you plan to add similar functionality to lockd? Then you can
>> just do the union in userland to figure out if it has been lifted.
>
> I don't think lockd needs to grow anything -- fs/nfs_common/grace.c
> already gives us both halves, and nfsd calls into both helpers today:
>
>   - locks_in_grace() is the union you describe: true while any lock
>     manager in the net ns is still in grace.
>
>   - opens_in_grace() is true only while a manager with ->block_opens
>     is in grace, which per the comment on struct lock_manager is the
>     NFSv4-and-up case; NLM doesn't set it.
>
> So for v2 I'll report locks_in_grace(), which answers "can this server
> hand out normal locks and opens yet" rather than "is nfsd's v4 lock
> manager done". If it's ever worth distinguishing the two, a second
> attribute carrying opens_in_grace() gets there without touching lockd,
> and userland can derive the NLM-only case as (locks && !opens). I'd
> rather not add that speculatively, but say the word if you'd like both
> in v2.

Although NFSD does not yet support putting individual exports in
grace, that is an open possibility for handling things like the
reboot of a backend NFS server for a re-exported NFS client. I'd
like any new API to avoid foreclosing the ability to move exports
in and out of grace individually rather than as a single unit.


-- 
Chuck Lever