> 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
