Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "Trond Myklebust" <trondmy@hammerspace.com>
Cc:     anna@kernel.org, linux-nfs@vger.kernel.org, neilb@suse.de
Subject: Re: [PATCH 0/2] NFS: limit use of ACCESS cache for negative responses
Date:   Fri, 26 Aug 2022 14:27:30 -0400
Message-ID: <FA952BF7-1638-4BD1-8DA9-683078CFDE8F@redhat.com>
In-Reply-To: <f5a2163d11f73e24c2106d43e72d0400d5a282b6.camel@hammerspace.com>
References: <165110909570.7595.8578730126480600782.stgit@noble.brown>
 <165274590805.17247.12823419181284113076@noble.neil.brown.name>
 <72f091ceaaf15069834eb200c04f0630eca7eaef.camel@hammerspace.com>
 <165274805538.17247.18045261877097040122@noble.neil.brown.name>
 <acdd578d2bb4551e45570c506d0948647d964f66.camel@hammerspace.com>
 <165274950799.17247.7605561502483278140@noble.neil.brown.name>
 <3ec50603479c7ee60cfa269aa06ae151e3ebc447.camel@hammerspace.com>
 <165275056203.17247.1826100963816464474@noble.neil.brown.name>
 <d6c351439c71d95f761c89533919850c91975639.camel@hammerspace.com>
 <D788BD7B-029F-4A4C-A377-81B117BD4CD2@redhat.com>
 <a56ca216aef75f419d8a13dd6c7719ef15bbcaab.camel@hammerspace.com>
 <54685EB8-7E6D-4EC4-8A9E-2BF55F41DABA@redhat.com>
 <f5a2163d11f73e24c2106d43e72d0400d5a282b6.camel@hammerspace.com>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On 26 Aug 2022, at 12:56, Trond Myklebust wrote:
> User group membership is not a per-mount thing. It's a global thing.

The cached access entry is a per-inode 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.

Sure there is - that's where we configure major NFS client behaviors.

I understand where you're coming from, but it seems so bizarre that a previous
behavior that multiple organizations built and depend upon has been removed
to optimize performance, and now we will need to tell them that to restore
it we must write cron jobs on all the clients.  I don't think there's been a
dependency on cron to get NFS to work a certain way yet.

A mount option is much easier to deploy in these organizations that have
autofs deployed, and documenting it in NFS(5) seems the right place.

If that's just not acceptable, at least let's just make a tuneable that
expires entries rather than a trigger to flush everything.  Please consider
the configuration sprawl on the NFS client, and let me know how to proceed.

Ben