On Fri, 2022-08-26 at 12:43 -0400, Benjamin Coddington wrote: > On 26 Aug 2022, at 11:44, Trond Myklebust wrote: > > > 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. > > A mount option would need to be set to enable the behavior, so the > cases > you're concerned about would be unaffected. > > > 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. > > We had the every-so-often flush per-inode before 57b691819ee2. > > Here's the setup in play: there's a large number of v3 clients and > users, > and many times each day group membership changes occur which either > restrict > or grant access to parts of the namespace. > > The feedback I'm getting is that it will be a lot of extra > orchestration to > have to trigger something on each client when the group memberships > change. > The desired behavior was as before 57b691819ee2: the access cache > expired > with the attribute timeout. It would be nice to have a mount option > that > could restore the access cache behavior as it was before > 57b691819ee2. > User group membership is not a per-mount thing. It's a global thing. As I said, what I'm proposing does allow you to set up a cron job that flushes your cache on a regular basis. There is absolutely no extra value whatsoever provided by moving that into the kernel on a per-mount basis. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
