On Mon, 2022-09-05 at 10:09 +1000, NeilBrown wrote: > On Mon, 05 Sep 2022, Trond Myklebust wrote: > > On Mon, 2022-09-05 at 09:28 +1000, NeilBrown wrote: > > > > > > When I was first presented with this problem I thought > > > logout/login > > > was > > > the answer and even provided a patch which would mean different > > > logins > > > got different cache keys. This wasn't very well received because > > > it > > > used to work without log out/in (because we didn't cache access > > > indefinitely), but the killer was that it didn't even work > > > reliably - > > > because of propagation variability. > > > > Then the onus is upon you and the people who don't want the two > > proposed solutions to figure out new ones. Timeouts are not > > acceptable. > > Why not? They have always been part of NFS. In moderation, yes. However we don't gratuitously fling them at every problem for the very good reason that they tend to create more problems than they solve. Look at the proliferation of mount options that already exist to solve the basic problem of tuning of all the timeouts that we already have. > But let's forget about timeouts for the moment. > You still haven't answered my question: What is the cost of not > caching > negative access results?? > What makes you think they are rare enough to compare to the 1 in a billion cases you're talking about? You're the one who is claiming without offering any shred of proof that negative results are rare. As far as I'm concerned, all it takes is $PATH component that does not have lookup rights set to allow 'other', or ditto for a library or config file path component. Alternatively, you happen to have a file that is not executable in $PATH, but with a name that matches a real executable further down the list. Suddenly you are hammering the server despite the fact that the permissions are never observed to change. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
