Odd namecache behaviour

[Reinoud Zandijk <reinoud%netbsd.org@localhost>]

Dear folks,

I stumbled upon code in cache_lookup (sys/kern/vfs_cache.c:600) that states:

            if (nameiop == CREATE && (cnflags & ISLASTCN) != 0) {
                    /*
                     * Last component and we are preparing to create
                     * the named object, so flush the negative cache
                     * entry.
                     */
                    COUNT(ncs_badhits);
                    cache_remove(ncp, true);
                    hit = false;
            } else {

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! This has as
a result that the directory is scanned AGAIN since the cache_lookup() returned
a non-hit instead of a negative-hit and the scan won't find the entry in the
directory of course as it was explicitly marked as such in the namecache so it
was all for nothing. FFS is masking this due to hacks to keep the last search
result around and/or the directory caching that it implements but other FSes
do need to scan again.

I'd propose to return true here indicating the negative hit and modify the
FSes to handle the negative hit correctly. I am not sure how much of a
performance gain this gives in practice but it eliminates double work.

Any thoughts about this?

With regards,
Reinoud