From: "J. Bruce Fields" <bfields@fieldses.org>
To: Scott Mayhew <smayhew@redhat.com>
Cc: jlayton@kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH v2 3/3] nfsd: keep a tally of RECLAIM_COMPLETE operations when using nfsdcld
Date: Wed, 19 Dec 2018 17:21:47 -0500 [thread overview]
Message-ID: <20181219222147.GA31570@fieldses.org> (raw)
In-Reply-To: <20181219220545.GS27213@coeurl.usersys.redhat.com>
On Wed, Dec 19, 2018 at 05:05:45PM -0500, Scott Mayhew wrote:
> On Wed, 19 Dec 2018, J. Bruce Fields wrote:
>
> > On Tue, Dec 18, 2018 at 09:29:26AM -0500, Scott Mayhew wrote:
> > > + if (!nfsd4_find_reclaim_client(clp->cl_name, nn))
> > > + return;
> > > + if (atomic_inc_return(&nn->nr_reclaim_complete) ==
> > > + nn->reclaim_str_hashtbl_size) {
> > > + printk(KERN_INFO "NFSD: all clients done reclaiming, ending NFSv4 grace period (net %x)\n",
> > > + clp->net->ns.inum);
> > > + nfsd4_end_grace(nn);
> > > + }
> > > +}
> > > +
> > > +static void dec_reclaim_complete(struct nfs4_client *clp)
> > > +{
> > > + struct nfsd_net *nn = net_generic(clp->net, nfsd_net_id);
> > > +
> > > + if (!nn->track_reclaim_completes)
> > > + return;
> > > + if (!test_bit(NFSD4_CLIENT_RECLAIM_COMPLETE, &clp->cl_flags))
> > > + return;
> > > + if (nfsd4_find_reclaim_client(clp->cl_name, nn))
> > > + atomic_dec(&nn->nr_reclaim_complete);
> > > +}
> > > +
> > > static void expire_client(struct nfs4_client *clp)
> > > {
> > > unhash_client(clp);
> > > nfsd4_client_record_remove(clp);
> > > + dec_reclaim_complete(clp);
> > > __destroy_client(clp);
> > > }
> >
> > This doesn't look right to me. If a client reclaims and then
> > immediately calls DESTROY_CLIENTID or something--that should still count
> > as a reclaim, and that shouldn't prevent us from ending the grace period
> > early.
> >
> > I think dec_reclaim_complete is unnecessary.
>
> What if a client sends a RECLAIM_COMPLETE, then reboots and sends an
> EXCHANGE_ID, CREATE_SESSION, and RECLAIM_COMPLETE while the server is
> still in grace? The count would be too high then and the server could
> exit grace before all the clients have reclaimed. I actually added
> that at Jeff's suggestion because he was seeing it with nfs-ganesha.
Oh boy.
(Thinks.)
Once it issues a DESTROY_CLIENTID or an EXCHANGE_ID that removes the
previous client instance's state, it's got no locks to reclaim any more.
(It can't have gotten any *new* ones, since we're still in the grace
period.)
It's effectively a brand new client. Only reclaiming clients should
bump that counter.
We certainly shouldn't be waiting for it to RECLAIM_COMPLETE to end the
grace period, that client just doesn't matter any more.
I think?
--b.
next prev parent reply other threads:[~2018-12-19 22:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-18 14:29 [PATCH v2 0/3] un-deprecate nfsdcld Scott Mayhew
2018-12-18 14:29 ` [PATCH v2 1/3] nfsd: make nfs4_client_reclaim use an xdr_netobj instead of a fixed char array Scott Mayhew
2018-12-18 14:29 ` [PATCH v2 2/3] nfsd: un-deprecate nfsdcld Scott Mayhew
2018-12-19 21:23 ` Jeff Layton
2018-12-19 22:11 ` Scott Mayhew
2018-12-20 0:19 ` Jeff Layton
2018-12-20 1:59 ` J. Bruce Fields
2018-12-20 15:24 ` Jeff Layton
2018-12-18 14:29 ` [PATCH v2 3/3] nfsd: keep a tally of RECLAIM_COMPLETE operations when using nfsdcld Scott Mayhew
2018-12-19 17:46 ` J. Bruce Fields
2018-12-19 21:57 ` Scott Mayhew
2018-12-19 18:28 ` J. Bruce Fields
2018-12-19 22:01 ` Scott Mayhew
2018-12-19 18:36 ` J. Bruce Fields
2018-12-19 22:05 ` Scott Mayhew
2018-12-19 22:21 ` J. Bruce Fields [this message]
2018-12-19 22:43 ` J. Bruce Fields
2018-12-20 16:36 ` Scott Mayhew
2018-12-20 17:32 ` Jeff Layton
2018-12-20 17:29 ` Jeff Layton
2018-12-20 18:05 ` J. Bruce Fields
2018-12-20 18:26 ` Jeff Layton
2018-12-20 19:02 ` J. Bruce Fields
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=20181219222147.GA31570@fieldses.org \
--to=bfields@fieldses.org \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=smayhew@redhat.com \
/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.