Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 10 Feb 2022 13:59:41 -0500
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
Message-ID: <20220210185941.GA24538@fieldses.org>
References: <1644468729-30383-1-git-send-email-dai.ngo@oracle.com>
 <1644468729-30383-4-git-send-email-dai.ngo@oracle.com>
 <20220210151759.GE21434@fieldses.org>
 <20220210163215.GH21434@fieldses.org>
 <2223051F-B8F5-4E59-8A27-735F6A426785@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2223051F-B8F5-4E59-8A27-735F6A426785@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

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.