Re: [PATCH 0/2] NFS: limit use of ACCESS cache for negative responses

[Trond Myklebust <trondmy@hammerspace.com>]

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@hammerspace.com