From: Bruce Fields <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: still seeing single client NFS4ERR_DELAY / CB_RECALL
Date: Sun, 9 Aug 2020 16:27:39 -0400 [thread overview]
Message-ID: <20200809202739.GA29574@fieldses.org> (raw)
In-Reply-To: <139C6BD7-4052-4510-B966-214ED3E69D61@oracle.com>
On Sun, Aug 09, 2020 at 01:11:36PM -0400, Chuck Lever wrote:
> Hi Bruce-
>
> I noticed that one of my tests takes about 4x longer on NFSv4.0 than
> it does on NFSv3 or NFSv4.[12]. As an initial stab at the cause, I'm
> seeing lots of these:
Oops, looks obvious in retrospect, but I didn't think of it.
In the 4.1+ case, sessions mean that we know which client every
operation comes from.
In the 4.0 case that only works for operations that take a stateid or
something else we can link back to a client.
That means in the 4.0 case delegations are less useful, since they have
to be broken on any (non-truncating) setattr, any link/unlink, etc.,
even if the operation comes from the same client--the server doesn't
have a way to know that.
Maybe the change to give out read delegations even on write opens
probably just isn't worth in the 4.0 case.
--b.
>
> <...>-283894 [003] 4060.507314: nfs4_xdr_status:
> task:51308@5 xid=0x1ec806a9 error=-10008 (DELAY)
> operation=34 <...>-283894 [003] 4060.507338: nfs4_setattr:
> error=-10008 (DELAY) fileid=00:27:258012 fhandle=0x25ef273d
> stateid=0:0x7bd5c66f <...>-283982 [006] 4060.508134:
> nfs4_state_mgr: hostname=klimt.ib clp
> state=CHECK_LEASE|0x4020 NFSv4-6239 [007] 4060.508137:
> nfs4_cb_recall: error=0 (OK) fileid=00:27:258012
> fhandle=0x25ef273d stateid=1:0x910c8d4c dstaddr=klimt.ib
>
> The workload is the git regression suite, which I run like this on a
> single client:
>
> --- mount test export ---
>
> $ cd /mnt; rm -rf git*; tar zvxf ~/Downloads/git-2.23.0.tar.gz
>
> --- remount test export ---
>
> $ cd /mnt/git*; make clean; make -j12
>
> --- remount test export ---
>
> $ cd /mnt/git*; make -j12 test
>
> -- Chuck Lever
>
>
next prev parent reply other threads:[~2020-08-09 20:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-09 17:11 still seeing single client NFS4ERR_DELAY / CB_RECALL Chuck Lever
2020-08-09 20:27 ` Bruce Fields [this message]
2020-08-09 21:25 ` Bruce Fields
2020-08-10 18:21 ` Chuck Lever
2020-08-10 19:07 ` Bruce Fields
2020-08-10 20:01 ` Chuck Lever
2020-08-10 20:10 ` Bruce Fields
2020-08-11 13:31 ` Chuck Lever
2020-08-16 20:46 ` Chuck Lever
2020-08-17 22:20 ` Bruce Fields
2020-08-18 15:27 ` Chuck Lever
2020-08-18 21:26 ` Chuck Lever
2020-08-18 21:49 ` Bruce Fields
2020-08-19 13:26 ` Chuck Lever
2020-08-19 21:29 ` Bruce Fields
2020-08-20 12:56 ` Chuck Lever
2020-08-24 13:39 ` Chuck Lever
2020-08-24 14:22 ` Bruce Fields
2020-08-24 15:42 ` Chuck Lever
2020-09-04 22:01 ` Bruce Fields
2020-09-04 22:27 ` Chuck Lever
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=20200809202739.GA29574@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.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