From: Peter Schubert <schubert@iap-kborn.de>
To: 郭玲兴 <guolingxing@supcon.com>, "Rick Macklem" <rick.macklem@gmail.com>
Cc: Lionel Cons <lionelcons1972@gmail.com>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] NFSv4.1 client hang in nfs4_drain_slot_tbl under concurrent workload against Windows NFS server
Date: Mon, 26 Oct 2026 08:45:54 +0100 [thread overview]
Message-ID: <9a8d698b-afd4-41a2-98f6-e062d33d71ff@iap-kborn.de> (raw)
In-Reply-To: <552f72d1.1c692.19e389e8ea4.Coremail.guolingxing@supcon.com>
Am 18.05.2026 um 03:06 schrieb 郭玲兴:
> Hi Rick, hi Lionel
>
> ..
>
> Regarding the "soft" mount option: understood. We will retest
> with a hard mount as well.
>
> One question is whether the observed behavior is expected.
> Even if a soft mount contributes to the problem, is it expected
> that a single RPC timeout can leave the client in a state with
> no forward progress, blocked in nfs4_drain_slot_tbl, and with
> lease renewal no longer occurring? Or would that more likely
> indicate a client-side recovery bug?
>
>
> Thanks,
> Guo Lingxing
>
>
Hi,
We performed one additional recovery test before rebooting the affected
client.
On Windows, the affected client still existed with |TotalSessions=0|,
but no session or open files.
We explicitly ran |Revoke-NfsMountedClient|for that client ID. The
client record disappeared completely on the server.
More than one 120-second NFSv4.1 lease period later, Windows still had
no client/session for that host, while the Linux NFS state-manager
remained blocked in |nfs4_drain_slot_tbl|and did not create a new session.
This suggests that once the client reaches this state, removing all
server-side client/session state does not trigger recovery; the Linux
client remains stuck waiting on its old local session state.
Regards,
Peter Schubert
prev parent reply other threads:[~2026-10-26 7:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 7:46 郭玲兴
2026-05-06 13:28 ` Lionel Cons
2026-05-07 0:50 ` 郭玲兴
2026-05-07 1:22 ` 郭玲兴
2026-05-16 14:23 ` Rick Macklem
2026-05-18 1:06 ` 郭玲兴
2026-10-22 7:50 ` Peter Schubert
2026-10-26 7:45 ` Peter Schubert [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9a8d698b-afd4-41a2-98f6-e062d33d71ff@iap-kborn.de \
--to=schubert@iap-kborn.de \
--cc=guolingxing@supcon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=lionelcons1972@gmail.com \
--cc=rick.macklem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®