On Fri, 17 Nov 2023, Jeff Layton wrote: > On Fri, 2023-11-17 at 13:18 +1100, NeilBrown wrote: > > For NFSv4.1 and later the client easily discovers if there is any > > admin-revoked state and will then find and explicitly free it. > > > > For NFSv4.0 there is no such mechanism. The client can only find that > > state is admin-revoked if it tries to use that state, and there is no > > way for it to explicitly free the state. So the server must hold on to > > the stateid (at least) for an indefinite amount of time. A > > RELEASE_LOCKOWNER request might justify forgetting some of these > > stateids, as would the whole clients lease lapsing, but these are not > > reliable. > > > > This patch takes two approaches. > > > > Whenever a client uses an revoked stateid, that stateid is then > > discarded and will not be recognised again. This might confuse a client > > which expect to get NFS4ERR_ADMIN_REVOKED consistently once it get it at > > all, but should mostly work. Hopefully one error will lead to other > > resources being closed (e.g. process exits), which will result in more > > stateid being freed when a CLOSE attempt gets NFS4ERR_ADMIN_REVOKED. > > > > Also, any admin-revoked stateids that have been that way for more than > > one lease time are periodically revoke. > > > > Why a single lease period? Because it was easy to code. > > Is that a long enough time for v4.0? Given that the protocol has no > mechanism to detect revoked state, I have to wonder if a single lease > period is enough time for the client to detect the problem? There is no amount of time that is long enough. In many cases the client will notice quickly. In some cases it might not notice for days or weeks. Given that there is no perfect solution, and given that v4.0 is really just a prototype that probably shouldn't be used any more, I don't think there is any benefit is trying any harder. Thanks, NeilBrown
