Re: NFS: nfs4_reclaim_open_state: Lock reclaim failed! log spew

["J. Bruce Fields" <bfields@fieldses.org>]

On Mon, Feb 29, 2016 at 06:53:15PM -0600, Jason L Tibbitts III wrote:
> >>>>> "JBF" == J Bruce Fields <bfields@fieldses.org> writes:
> 
> JBF> Argh, it's all encrypted, so we all we have to go on is the size of
> JBF> the request and reply:
> 
> Yeah, I'm not sure how to get around that.  I know tshark can take a
> keytab, but the user's key is in the kernel keyring and I'm not at all
> sure how to dig it out (assuming I even can).  But if there's something
> I can do, I can try.
> 
> I could switch to krb5i or plain krb for a while if that would be
> useful, except that the clients would prefer krb5p if it's exported, and
> if I stop exporting it then existing mounts break....  I'd have to
> schedule downtime and kick everyone off, which I could do if it would
> help.

I believe the order of flavors in the sec= option is the order they're
given to the client, so reversing it might cause new clients to make a
different choice--but I'm not actually sure of the logic there.

> 
> JBF> The best you could do is capture all traffic and throw away all but
> JBF> the last few seconds (see the ring buffer stuff in tshark) and
> JBF> write a script that kills the capture as soon as it notices you've
> JBF> hit this condition.
> 
> If I knew how to detect the condition, though, I have a feeling that
> would be enough information to track down the bug anyway.
> 
> Also, I'd have to do this for a couple of hundred clients.  Ugh.

Yeah, don't worry about it, I was just thinking aloud.

--b.