From: Bruce Fields <bfields@fieldses.org>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Dai Ngo <dai.ngo@oracle.com>, Jeff Layton <jlayton@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH RFC v9 2/2] nfsd: Initial implementation of NFSv4 Courteous Server
Date: Wed, 12 Jan 2022 13:53:27 -0500 [thread overview]
Message-ID: <20220112185327.GA10518@fieldses.org> (raw)
In-Reply-To: <D2CF771C-FF71-4356-8567-33427EAC0DA9@oracle.com>
On Tue, Jan 11, 2022 at 03:49:19PM +0000, Chuck Lever III wrote:
> > On Jan 10, 2022, at 8:03 PM, Dai Ngo <dai.ngo@oracle.com> wrote:
> > I think this is something you and Bruce have been discussing
> > on whether when we should remove and add the client record from
> > the database when the client transits from active to COURTESY
> > and vice versa. With this patch we now expire the courtesy clients
> > asynchronously in the background so the overhead/delay from
> > removing the record from the database does not have any impact
> > on resolving conflicts.
>
> As I recall, our idea was to record the client as expired when
> it transitions from active to COURTEOUS so that if the server
> happens to reboot, it doesn't allow a courteous client to
> reclaim locks the server may have already given to another
> active client.
>
> So I think the server needs to do an nfsdtrack upcall when
> transitioning from active -> COURTEOUS to prevent that edge
> case. That would happen only in the laundromat, right?
>
> So when a COURTEOUS client comes back to the server, the server
> will need to persistently record the transition from COURTEOUS
> to active.
Yep. The bad case would be:
- client A is marked DESTROY_COURTESY, client B is given A's
lock.
- server goes down before laundromat thread removes the
DESTROY_COURTESY client.
- client A's network comes back up.
- server comes back up and starts grace period.
At this point, both A and B believe they have the lock. Also both still
have nfsdcltrack records, so the server can't tell which is in the
right.
We can't start granting A's locks to B until we've recorded in stable
storage that A has expired.
What we'd like to do:
- When a client transitions from active to courteous, it needs
to do nfsdcltrack upcall to expire it.
- We mark client as COURTESY only after that upcall has
returned.
- When the client comes back, we do an nfsdcltrack upcall to
mark it as active again. We don't remove the COURTESY mark
until that's returned.
--b.
next prev parent reply other threads:[~2022-01-12 18:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-10 18:50 [PATCH RFC v9 0/2] nfsd: Initial implementation of NFSv4 Courteous Server Dai Ngo
2022-01-10 18:50 ` [PATCH RFC v9 1/2] fs/lock: add new callback, lm_expire_lock, to lock_manager_operations Dai Ngo
2022-01-10 18:50 ` [PATCH RFC v9 2/2] nfsd: Initial implementation of NFSv4 Courteous Server Dai Ngo
2022-01-10 23:17 ` Chuck Lever III
2022-01-11 1:03 ` dai.ngo
2022-01-11 15:49 ` Chuck Lever III
2022-01-12 18:53 ` Bruce Fields [this message]
2022-01-12 18:56 ` dai.ngo
2022-01-12 19:40 ` J. Bruce Fields
2022-01-13 8:51 ` dai.ngo
2022-01-13 15:42 ` J. Bruce Fields
2022-01-13 19:51 ` dai.ngo
2022-01-12 19:52 ` J. Bruce Fields
2022-01-10 19:03 ` [PATCH RFC v9 0/2] " Chuck Lever III
2022-01-12 18:59 ` J. Bruce Fields
2022-01-12 19:05 ` dai.ngo
2022-01-12 19:21 ` J. Bruce Fields
2022-01-12 19:31 ` dai.ngo
2022-01-12 19:42 ` J. Bruce Fields
2022-01-12 20:34 ` dai.ngo
2022-01-12 20:39 ` J. Bruce Fields
-- strict thread matches above, loose matches on Subject: below --
2022-01-10 18:40 Dai Ngo
2022-01-10 18:40 ` [PATCH RFC v9 2/2] " Dai Ngo
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=20220112185327.GA10518@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=jlayton@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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).