Re: [PATCH RFC v12 3/3] nfsd: Initial implementation of NFSv4 Courteous Server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On Feb 10, 2022, at 1:59 PM, Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
> 
> 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@xxxxxxxxxxxx> 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.

I don't disagree that a good quality server implementation should
handle the post-server-reboot case a little nicer. I would like to
avoid losing momentum on the current patch set, though.

Support for post-server-reboot courtesy can be phase 1.5.


--
Chuck Lever







[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux