From: "J. Bruce Fields" <bfields@fieldses.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: Scott Mayhew <smayhew@redhat.com>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH v2 3/3] nfsd: keep a tally of RECLAIM_COMPLETE operations when using nfsdcld
Date: Thu, 20 Dec 2018 13:05:36 -0500 [thread overview]
Message-ID: <20181220180536.GE6063@fieldses.org> (raw)
In-Reply-To: <901adec26f1fd20259bd3e50d963f304b903d312.camel@kernel.org>
On Thu, Dec 20, 2018 at 12:29:43PM -0500, Jeff Layton wrote:
> That wasn't my thinking here.
>
> Suppose we have a client that holds some locks. Server reboots and we do
> EXCHANGE_ID and start reclaiming, and eventually send a
> RECLAIM_COMPLETE.
>
> Now, there is a network partition and we lose contact with the server
> for more than a lease period. The client record gets tossed out. Client
> eventually reestablishes the connection before the grace period ends and
> attempts to reclaim.
>
> That reclaim should succeed, IMO, as there is no reason that it
> shouldn't. Nothing can have claimed competing state since we're still in
> the grace period.
That scenario requires a grace period longer than the lease period,
which isn't impossible but sounds rare? I guess you're thinking in the
cluster case about the possibility of a second node failure extending
the grace period.
Still, that's different from the case where the client explicitly
destroys its own state. That could happen in less than a lease period
and in that case there won't be a reclaim. I think that case could
happen if a client rebooted quickly or maybe just unmounted.
Hm.
--b.
next prev parent reply other threads:[~2018-12-20 18:05 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
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 [this message]
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=20181220180536.GE6063@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.