Re: Odd namecache behaviour

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 23 Jan 2025 12:35:57 +0100
    From:        Reinoud Zandijk <reinoud%netbsd.org@localhost>
    Message-ID:  <Z5IpnbHNMVFLfPoy%dropje.13thmonkey.org@localhost>


  | i.e. it removes a negative namecache entry on create as might be expected
  | as it will be created after this call BUT it also returns a non-hit!

I haven't been near the name cache code for many decades, and I doubt
that particular piece was there from when it was created (I suspect
negative caching didn't exist in the early forms) but if I had to guess
it would be that when the intent is to create a new entry, a specific
negative entry (name does not exist) and the name simply not existing
at all, are essentially the same thing (particularly after the entry
has been removed) and so the response to the two cases should be the
same.

That is, the filesystem already has to deal with the case that no entry
for the name ever existed, adding extra complexity to it to deal with the
very similar case "no entry for the name exists, but someone asked about
it previously" (which is what the negative cache entry indicates) seems
like it would be counter productive, even if it could make the code
fractionally more efficient.

I see no direct problem with attempting to change this (provided all
clients are also changed to deal with it) - but before committing anything
I'd expect to see benchmarks indicating a measurable gain in overall
performance (those could be done before wasting time converting all
filesystems to the new model) that are sufficient to compensate for the
added complexity, and larger code that will almost certainly result.

kre