From: Trond Myklebust <trondmy@hammerspace.com>
To: "aglo@umich.edu" <aglo@umich.edu>,
"jencce.kernel@gmail.com" <jencce.kernel@gmail.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] NFSv4: fix stateid refreshing when CLOSE racing with OPEN
Date: Fri, 11 Oct 2019 14:18:43 +0000 [thread overview]
Message-ID: <2597b15558e1195436db68f019899694c796fef6.camel@hammerspace.com> (raw)
In-Reply-To: <CAN-5tyGKNFsxQHne4hFhON1VRZzCkUjwFMX3ZuzfLASgEN0pMw@mail.gmail.com>
On Thu, 2019-10-10 at 13:32 -0400, Olga Kornievskaia wrote:
> On Thu, Oct 10, 2019 at 3:42 AM Murphy Zhou <jencce.kernel@gmail.com>
> wrote:
> > Since commit:
> > [0e0cb35] NFSv4: Handle NFS4ERR_OLD_STATEID in
> > CLOSE/OPEN_DOWNGRADE
> >
> > xfstests generic/168 on v4.2 starts to fail because reflink call
> > gets:
> > +XFS_IOC_CLONE_RANGE: Resource temporarily unavailable
>
> I don't believe this failure has to do with getting ERR_OLD_STATEID
> on
> the CLOSE. What you see on the network trace is expected as the
> client
> in parallel sends OPEN/CLOSE thus server will fail the CLOSE with the
> ERR_OLD_STATEID since it already updated its stateid for the OPEN.
>
> > In tshark output, NFS4ERR_OLD_STATEID stands out when comparing
> > with
> > good ones:
> >
> > 5210 NFS 406 V4 Reply (Call In 5209) OPEN StateID: 0xadb5
> > 5211 NFS 314 V4 Call GETATTR FH: 0x8d44a6b1
> > 5212 NFS 250 V4 Reply (Call In 5211) GETATTR
> > 5213 NFS 314 V4 Call GETATTR FH: 0x8d44a6b1
> > 5214 NFS 250 V4 Reply (Call In 5213) GETATTR
> > 5216 NFS 422 V4 Call WRITE StateID: 0xa818 Offset: 851968 Len:
> > 65536
> > 5218 NFS 266 V4 Reply (Call In 5216) WRITE
> > 5219 NFS 382 V4 Call OPEN DH: 0x8d44a6b1/
> > 5220 NFS 338 V4 Call CLOSE StateID: 0xadb5
> > 5222 NFS 406 V4 Reply (Call In 5219) OPEN StateID: 0xa342
> > 5223 NFS 250 V4 Reply (Call In 5220) CLOSE Status:
> > NFS4ERR_OLD_STATEID
> > 5225 NFS 338 V4 Call CLOSE StateID: 0xa342
> > 5226 NFS 314 V4 Call GETATTR FH: 0x8d44a6b1
> > 5227 NFS 266 V4 Reply (Call In 5225) CLOSE
> > 5228 NFS 250 V4 Reply (Call In 5226) GETATTR
>
> "resource temporarily unavailable" is more likely to do with ulimit
> limits.
>
> I also saw the same error. After I increased the ulimit for the stack
> size, the problem went away. There might still be a problem somewhere
> in the kernel.
>
> Trond, is it possible that we have too many CLOSE recovery on the
> stack that's eating up stack space?
That shouldn't normally happen. CLOSE runs as an asynchronous RPC call,
so its stack usage should be pretty minimal (limited to whatever each
callback function uses).
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
next prev parent reply other threads:[~2019-10-11 14:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-10 7:40 [PATCH] NFSv4: fix stateid refreshing when CLOSE racing with OPEN Murphy Zhou
2019-10-10 14:46 ` Trond Myklebust
2019-10-11 8:49 ` Murphy Zhou
2019-10-11 14:14 ` Trond Myklebust
2020-09-03 17:54 ` Benjamin Coddington
2020-09-04 3:04 ` Murphy Zhou
2020-09-04 10:55 ` Benjamin Coddington
2020-09-04 14:14 ` Chuck Lever
2020-09-08 12:43 ` Benjamin Coddington
2020-09-04 16:13 ` Olga Kornievskaia
2019-10-10 17:32 ` Olga Kornievskaia
2019-10-11 9:42 ` Murphy Zhou
2019-10-11 14:18 ` Trond Myklebust [this message]
2019-10-11 18:50 ` Olga Kornievskaia
2019-10-19 0:34 ` Olga Kornievskaia
2019-10-21 17: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=2597b15558e1195436db68f019899694c796fef6.camel@hammerspace.com \
--to=trondmy@hammerspace.com \
--cc=aglo@umich.edu \
--cc=jencce.kernel@gmail.com \
--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).