In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>
>:
>:In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>:
>:> Again, keep in mind that the namei cache is strictly throw-away, but
>:> entries can often be reconstituted later by the filesystem without I/O
>:> due to the VM Page cache (and/or buffer cache depending on
>:> vfs.vmiodirenable). So as with the buffer cache and inode cache,
>:> the number of entries can be limited without killing performance or
>:> scaleability.
>:
>:Uhm, that is actually not true.
>:
>:We keep namecache entries around as long as we can use them, and that
>:generally means that recreating them is a rather expensive operation,
>:involving creation of vnode and very likely a vm object again.
>
> The vnode cache is a different cache. positive namei hits will
> reference a vnode, but namei elements can be flushed at any
> time without flushing the underlying vnode.
Right, but doing so means that to refind that vnode from the name
is (comparatively) very expensive.
--
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
