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 v12 3/3] nfsd: Initial implementation of NFSv4 Courteous Server
Date: Thu, 10 Feb 2022 13:59:41 -0500 [thread overview]
Message-ID: <20220210185941.GA24538@fieldses.org> (raw)
In-Reply-To: <2223051F-B8F5-4E59-8A27-735F6A426785@oracle.com>
On Thu, Feb 10, 2022 at 04:52:15PM +0000, Chuck Lever III wrote:
>
> > On Feb 10, 2022, at 11:32 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> >
> > I was standing in the shower thinking....
> >
> > We're now removing the persistent client record early, after the first
> > lease period expires, instead of waiting till the first lock conflict.
> >
> > That simplifies conflict handling.
> >
> > It also means that all clients lose their locks any time a crash or
> > reboot is preceded by a network partition of longer than a lease period.
> >
> > Which is what happens currently, so it's no regression.
> >
> > Still, I think it will be a common case that it would be nice to handle:
> > there's a network problem, and as a later consequence of the problem or
> > perhaps a part of addressing it, the server gets rebooted. There's no
> > real reason to prevent clients recovering in that case.
> >
> > Seems likely enough that it would be worth a little extra complexity in
> > the code that handles conflicts.
> >
> > So I'm no longer convinced that it's a good tradeoff to remove the
> > persistent client record early.
>
> Would it be OK if we make this change after the current work is merged?
Your choice! I don't have a strong opinion.
--b.
next prev parent reply other threads:[~2022-02-10 18:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-10 4:52 [PATCH RFC v12 0/3] nfsd: Initial implementation of NFSv4 Courteous Server Dai Ngo
2022-02-10 4:52 ` [PATCH RFC v12 1/3] fs/lock: add new callback, lm_lock_conflict, to lock_manager_operations Dai Ngo
2022-02-10 14:21 ` J. Bruce Fields
2022-02-10 14:29 ` Jeff Layton
2022-02-10 19:41 ` dai.ngo
2022-02-10 19:44 ` Chuck Lever III
2022-02-10 19:56 ` dai.ngo
2022-02-10 14:28 ` J. Bruce Fields
2022-02-10 16:50 ` Chuck Lever III
2022-02-10 17:32 ` Jeff Layton
2022-02-10 19:47 ` dai.ngo
2022-02-10 4:52 ` [PATCH RFC v12 2/3] fs/lock: only call lm_breaker_owns_lease if there is conflict Dai Ngo
2022-02-10 4:52 ` [PATCH RFC v12 3/3] nfsd: Initial implementation of NFSv4 Courteous Server Dai Ngo
2022-02-10 15:17 ` J. Bruce Fields
2022-02-10 16:32 ` J. Bruce Fields
2022-02-10 16:52 ` Chuck Lever III
2022-02-10 18:59 ` Bruce Fields [this message]
2022-02-10 19:04 ` Chuck Lever III
2022-02-10 19:52 ` 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=20220210185941.GA24538@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.