> On Thu, Dec 03, 2020 at 10:53:26PM +0000, Trond Myklebust wrote: > > On Thu, 2020-12-03 at 17:45 -0500, bfields@xxxxxxxxxxxx wrote: > > > On Thu, Dec 03, 2020 at 09:34:26PM +0000, Trond Myklebust wrote: > > > > I've been wanting such a function for quite a while anyway in > > > > order to allow the client to detect state leaks (either due to > > > > soft timeouts, or due to reordered close/open operations). > > > > > > One sure way to fix any state leaks is to reboot the server. The > > > server throws everything away, the clients reclaim, all that's left > > > is stuff they still actually care about. > > > > > > It's very disruptive. > > > > > > But you could do a limited version of that: the server throws away > > > the state from one client (keeping the underlying locks on the > > > exported filesystem), lets the client go through its normal reclaim > > > process, at the end of that throws away anything that wasn't > > > reclaimed. The only delay is to anyone trying to acquire new locks > > > that conflict with that set of locks, and only for as long as it > > > takes for the one client to reclaim. > > > > One could do that, but that requires the existence of a quiescent > > period where the client holds no state at all on the server. > > No, as I said, the client performs reboot recovery for any state that it holds > when we do this. Yea, but the original sever goes through a period where it has dropped all state and isn't in grace, and if it's coordinating with non-NFS users, they don't know anything about grace anyway. Frank
