Thanks for working on this, it's currently a major annoyance! On Fri, Aug 15, 2014 at 10:45:08AM -0400, Jeff Layton wrote: > This patchset adds some support to sm-notify and nfsdcltrack for lifting > the grace periods early. Allowing this actually work depends on the > companion kernel patchset, but the approach I've taken here should deal > properly with userland/kernel mismatch. > > There are two main pieces: > > sm-notify: in the event that sm-notify isn't sending any NOTIFY > requests, we don't expect to see any reclaims from clients. In that > case, we should be able to safely lift the lockd grace period early. > The first patch in the series implements this (though we'll probably > need a bit of selinux work to get that working in Fedora under enforcing > mode). > > nfsdcltrack: if there are no v4.0 clients and all v4.1+ clients have > issued a RECLAIM_COMPLETE, then we can go ahead and end the nfsd grace > period. The remainder of the patchset adds the support for this. This > requires revving the DB schema for it, and making use of the environment > variables that are passed to the upcall by the kernel. And we get to skip the grace period on first start, and on any restart during which no clients hold state, which seem like big improvements on their own. Mostly a pointless digression, but I've been wondering if there are any further improvements that are worth it. I'm feeling skeptical: As long as nobody uses deny modes we could deal with them with a big dumb hammer (e.g. synchronously record something if anyone requests one, insist on a full grace period if they do). But we're still stuck blocking all new opens as long as there are delegations outstanding. (Well, maybe only new read opens, until we get write delegations.) Would it work to record a count of delegations on shutdown, to speed up the restart-after-clean-shutdown case? And if it worked, would it be worth the effort? (Alternatively on shutdown we could stop giving out delegations, recall everything, and wait till we had no delegations till shutting down completely. Wonder how painful that would be.) So anyway maybe our best bet is just to hope people upgrade to 4.1 soon. --b. > > Again, this is just an RFC set for now. Does anyone have thoughts or > comments on the general approach? > > Jeff Layton (7): > sm-notify: inform the kernel if there were no hosts to notify > nfsdcltrack: update comments in sqlite.c > nfsdcltrack: rename CLD_* constants with CLTRACK_* prefixes > nfsdcltrack: overhaul database initializtion > nfsdcltrack: update schema to v2 > nfsdcltrack: grab the client minorversion from the env var if it's > present > nfsdcltrack: fetch NFSDCLTRACK_GRACE_START out of environment > > utils/nfsdcltrack/nfsdcltrack.c | 106 +++++++++++- > utils/nfsdcltrack/sqlite.c | 375 ++++++++++++++++++++++++++++++---------- > utils/nfsdcltrack/sqlite.h | 5 +- > utils/statd/sm-notify.c | 25 +++ > 4 files changed, 413 insertions(+), 98 deletions(-) > > -- > 1.9.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
