From: Jeff Layton <jlayton@kernel.org>
To: Harald Dunkel <harald.dunkel@aixigo.de>, linux-nfs@vger.kernel.org
Subject: Re: nfs4_reclaim_open_state: Lock reclaim failed!
Date: Tue, 04 Sep 2018 08:11:55 -0400 [thread overview]
Message-ID: <c78c32d78e2d45665336a5a441ee79546858b729.camel@kernel.org> (raw)
In-Reply-To: <cf2e08fb-7130-d40f-fa93-bf805c87b770@aixigo.de>
On Tue, 2018-09-04 at 09:31 +0200, Harald Dunkel wrote:
> Hi Jeff,
>
> On 9/3/18 11:32 AM, Jeff Layton wrote:
> >
> > Yes, typically a server reboot will cause the client to reclaim its
> > state. If the server isn't restarting then you probably have a situation
> > where the client and server have gotten out of sync in some fashion, the
> > client is realizing it and attempting to reclaim its state.
> >
> > One thing that could (potentially) cause this is a nfs4_unique_id
> > collision. You might want to survey your clients and ensure that there
> > aren't any.
> >
>
> /sys/module/nfs/parameters/nfs4_unique_id tells me that the default
> is an empty string. Thats hard to believe. I had expected the default
> is derived from the mac address of eth0 or something like this. ???
>
> All explicitly defined nfs4_unique_id are unique, I checked (on the
> Linux hosts). il06 (the NFS client here) and 4 other ancient servers
> *were* running with the default "unique" id. My fault.
>
In general, the long-form clientid needs to be unique for each client.
nfs4_unique_id is just a uniquifier for the long-form client ID string.
If it's blank then it'll just use the current nodename (hostname)
without one. If you have uniquifier collisions among hosts with
different hostnames, then you'll still get different strings. See
nfs4_init_uniform_client_string() in the kernel sources for details.
> > > Would you recommend to stick with NFS 4(.0) or NFS 3, avoiding the
> > > new code in NFS 4.{1,2}? Which NFS version in 4.9 or another LTS
> > > kernel suits best for production use?
> > >
> >
> > v4.1+ are fine (in general) for production, but there are always bugs.
> >
>
> How do NFS version numbers on client and Linux server affect each
> other? AIX 7.1 (just as an example) supports just "nfs" and "nfs4",
> not "nfs4.1" or "nfs4.2". Will the AIX clients benefit from the bug
> fixes included in Linux' nfs 4.1+?
>
I'm not sure -- it really depends on whether AIX supports v4.1+.
In general, the server will "advertise" what versions it supports and
the Linux client will negotiate to the highest supported version. I'm
not sure what other clients will do.
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2018-09-04 16:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-29 9:09 nfs4_reclaim_open_state: Lock reclaim failed! Harald Dunkel
2018-08-29 9:13 ` Harald Dunkel
2018-08-31 11:49 ` Jeff Layton
2018-09-03 8:34 ` Harald Dunkel
2018-09-03 9:32 ` Jeff Layton
2018-09-04 7:31 ` Harald Dunkel
2018-09-04 12:11 ` Jeff Layton [this message]
2018-08-31 15:41 ` Olga Kornievskaia
2018-09-03 7:48 ` Harald Dunkel
2018-09-03 13:15 ` Olga Kornievskaia
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=c78c32d78e2d45665336a5a441ee79546858b729.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=harald.dunkel@aixigo.de \
--cc=linux-nfs@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).