All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harald Dunkel <harald.dunkel@aixigo.de>
To: Jeff Layton <jlayton@kernel.org>, linux-nfs@vger.kernel.org
Subject: Re: nfs4_reclaim_open_state: Lock reclaim failed!
Date: Tue, 4 Sep 2018 09:31:22 +0200	[thread overview]
Message-ID: <cf2e08fb-7130-d40f-fa93-bf805c87b770@aixigo.de> (raw)
In-Reply-To: <4aa0284e9f2d4b7994aa976926fd1a84493ee228.camel@kernel.org>

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.

>> 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+?


Regards
Harri

  reply	other threads:[~2018-09-04 11:55 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 [this message]
2018-09-04 12:11           ` Jeff Layton
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=cf2e08fb-7130-d40f-fa93-bf805c87b770@aixigo.de \
    --to=harald.dunkel@aixigo.de \
    --cc=jlayton@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.