On Fri, 2022-08-26 at 10:59 -0400, Benjamin Coddington wrote: > On 16 May 2022, at 21:36, Trond Myklebust wrote: > > So until you have a different solution that doesn't impact the > > client's > > ability to cache permissions, then the answer is going to be "no" > > to > > these patches. > > Hi Trond, > > We have some folks negatively impacted by this issue as well. Are > you > willing to consider this via a mount option? > > Ben > I don't see how that answers my concern. I'd rather see us set up an explicit trigger mechanism. It doesn't have to be particularly sophisticated. I can imagine just having a global, or more likely a per-container, cookie that has a control mechanism in /sys/fs/nfs, and that can be used to order all the inodes to invalidate their permissions caches when you believe there is a need to do so. i.e. you cache the value of the global cookie in the inode, and if you notice a change, then that's the signal that you need to invalidate the permissions cache before updating the cached value of the cookie. That way, you have a mechanism that serves all purposes: it can do an immediate one-time only flush, or you can set up a userspace job that issues a global flush once every so often, e.g. using a cron job. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
