DragonFlyBSD

: link("sin.c", id);

There is no easy fix for this, the current vfs cache kinda depends
    on the vnode limit to indirectly control its size and hard links
    defeat the vnode limit (since one can have many hard links to the
    same vnode).

-Matt

In the cache_nlookup() code, when we cache_alloc() a namecache structure:
2273 if (new_ncp == NULL) {
2274 spin_unlock(&nchpp->spin);
2275 new_ncp = cache_alloc(nlc->nlc_namelen);
2276 if (nlc->nlc_namelen) {
2277 bcopy(nlc->nlc_nameptr, new_ncp->nc_name,
2278 nlc->nlc_namelen);
2279 new_ncp->nc_name[nlc->nlc_namelen] = 0;
2280 }
2281 goto restart;
2282 }

We restart the lookup after the allocation; the restarted lookup is safe
against a null namecache ptr, the straightline path starts with a null ncp.
2226 new_ncp = NULL;
2227 nchpp = NCHHASH;
2228 restart:
2229 spin_lock(&nchpp->spin);

If we allow cache_alloc to return null, we could modify the lookup path to call
cache_cleanneg() to try to get back some space, at least from negative entries,
and then restart the lookup, at least a few times. AFAICS, there is no way to
clean out positive entries? This doesn't solve the problem, but it does put it
off somewhat.

More towards a solution, we could return an unresolved cache structure to the
caller if we cannot allocate an ncp; the callers of cache_nlookup (in particular
nlookup() itself seem to be safe against lookup failures, they just retry the
search...

:If we allow cache_alloc to return null, we could modify the lookup path to call
:cache_cleanneg() to try to get back some space, at least from negative entries,
Negative hits aren't the problem. Having all the ncp's associated with
just a few vnodes means the normal vnode pressure will not clear them
out, because the vnodes are not under pressure.

We don't want the allocation in the loop to fail, we want it to
    clean out some ncps prior to entering the loop I think.

-Matt

Okay - presumably we only want to clean out ncps if there is pressure on the
zone without vnode pressure. Would tracking the link : vnode ratio and cleaning
namecache entries before entering the loop based on that ratio be worth doing?
Currently are there interfaces to ask the namecache to clean itself?
(vnlrureclaim() seems brutal)...

Currently ncp->name is also allocated from the VFSCACHE zone, along with
namecache hashes; moving them to private zones would reduce load on the VFSCACHE
zone, and those zones would be implicitly limited by the vnode limit and
whatever limiting on ncps is there...

I've started working on a fix for this in the vfscache branch on my repository on
leaf...

Fixed by commit 9e10d70bff3c00c19a8b841dccbcd6aa29100793 to master; cleans out
positive and negative namecache entries via cache_hysteresis even on namecache
lookups.

What could be different?
- measure impact on nc hitrate
- see if its still possible to exhaust the zone, given huge filenames and lots
of links.