In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>
>:
>:On Tue, 10 Apr 2001, Matt Dillon wrote:
>:
>:> It's randomness that will kill performance. You know the old saying
>:> about caches: They only work if you get cache hits, otherwise
>:> they only slow things down.
>:
>:I wonder ... how does FreeBSD handle negative directory entries?
>:
>:That is, /bin/sh looks through the PATH to search for some executable
>:(eg grep) and doesn't find it in the first 3 directories.
>:
>:Does the vfs cache handle this or does FreeBSD have to go down into
>:the filesystem code every time?
>:
>:Rik
>
> The namei cache stores negative hits. /usr/src/sys/kern/vfs_cache.c
> cache_lookup() - if ncp->nc_vp (the vnode) is NULL, the cache entry
> represents a negative hit. cache_enter() - vp may be passed as NULL
> to create a negative cache entry. ufs/ufs/ufs_lookup.c, calls to
> cache_enter() enters positive or negative lookups as appropriate.
>
You should also know that negative entries, since they have no
objects to "hang from" and consequently would clog up the name-cache,
are limited by the sysctl:
debug.ncnegfactor: 16
which means that max 1/16 of the name cache entries can be negative
entries. You can monitor the number of negative entries with the
sysctl
debug.numneg: 305
the value of "16" was rather arbitrarily chosen and better defaults
may exist.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
