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

["bfields@fieldses.org" <bfields@fieldses.org>]

On Thu, Nov 17, 2016 at 10:43:58PM +0000, Trond Myklebust wrote:
> On Thu, 2016-11-17 at 17:27 -0500, Olga Kornievskaia wrote:
> > On Thu, Nov 17, 2016 at 5:15 PM, Trond Myklebust
> > <trondmy@primarydata.com> wrote:
> > > What's the alternative? Assume the client pre-emptively bumps the
> > > seqid
> > > instead of retrying, then the user presses Ctrl-C again. Repeat a
> > > few
> > > more times. How do I now resync the seqids between the client and
> > > server other than by trashing the session?
> > 
> > I don't see any alternatives than to reset in that case. But I think
> > it's better then the possibility of accidentally opening a wrong
> > file?

Remind me why you can't continue resending after the Ctrl-C?  (I thought
this was already done for some lock and other cases?)

> They sound equally bad to me which is why I'm not understanding how a
> server would fail to implement some minimal form of false retry
> checking.
> The Linux NFSv3 DRC will, for instance, checksum at least some part of
> the RPC arguments for _all_ RPC calls. Most NFSv4.x clients will only
> ask that you checksum the non-idempotent RPC calls, which significantly
> cuts down on the calculation overhead.

I'll look at adding checksumming, it shouldn't be hard.

--b.