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: 23+ 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 20:52 ` kernel test robot
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 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.