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. There are definitely cases where that is not an option. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
