Date: Sun, 15 Apr 2001 13:01:37 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Doug Barton <DougB@DougBarton.net> Cc: "'current@freebsd.org'" <current@FreeBSD.ORG> Subject: Re: FW: Filesystem gets a huge performance boost Message-ID: <200104152001.f3FK1bE71555@earth.backplane.com> References: <200104101103.f3AB36P49523@hak.lan.Awfulhak.org> <200104101824.f3AIOZ389340@earth.backplane.com> <3AD90956.998BE3E7@DougBarton.net>
index | next in thread | previous in thread | raw e-mail
:
: I notice that this option is off by default. Can you give a general idea
:of when it should be enabled, when it should be disabled, and what bad
:things might result with it on?
:
:Thanks,
:
:Doug
There's no downside, really. The directory cache is so tiny without
it that you can't lose. Even the wasteage from caching small directories
becomes irrelevant -- for several reasons. First, wasting a little bit
of ram is worth it if it saves a disk seek. It saves lots of disk seeks.
Second, people forget that the namei cache is the first line of defense
for the system, not the directory block cache. Most programmatic small
directory accesses directly reference specific files rather then scan
the directory. Human-based accesses often scan the directory (do
an 'ls'), but the memory footprint for a human is huge in comparison to
a single page of directory cache. Scanning whole filesystems with 'find'
tend to not be cacheable anyway, and since the cache pages get recycled
you don't actually waste any more ram for that case either.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104152001.f3FK1bE71555>