Date: Mon, 19 Apr 1999 16:30:58 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Polstra <jdp@polstra.com> Cc: hackers@freebsd.org Subject: Re: Directories not VMIO cached at all! Message-ID: <199904192330.QAA91277@apollo.backplane.com> References: <199904191650.JAA24137@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:In article <199904171844.LAA75452@apollo.backplane.com>,
:Matthew Dillon <dillon@apollo.backplane.com> wrote:
:
:> When I scan enough directories ( e.g. a megabyte worth of directories
:> on a 1 GB machine), then scan again, the data is re-fetched from disk.
:
:If I understand your description correctly, this fix could really
:benefit master CVSup servers such as freefall. Those servers
:typically have 8-12 running cvsupd processes, all doing tree walks
:over the same CVS repository and making a stat() call on every file.
:
:Do you think it would help?
:
:John
Yes, but you can't apply the VMIO fix to the 3.x tree if you are also
using NFS. NFS will barf on it. I believe my patch to NFS that solves
the VMIO problem can be backported to -3.x, though, if you want to try
the combination.
It's a two line patch to a simple bug: NFS depends on the buffer's
b_resid field to represent the EOF of the file. This works as long as
the buffer is a B_MALLOC buffer (i.e. its backing store goes away when
the buffer goes away). If the buffer is a B_VMIO buffer, though, the
buffer can go away and the backing store will be saved in the VM
cache. If the buffer is then later reconstituted, b_resid is set to 0
and no longer represents the actual EOF of the directory, causing
getdirentries() to screw up. NFS happens to remember the offset of the
directory eof in the np structure, so the two-line fix is to impose
that on top of the b_resid test when looking for the directory EOF within
the buffer.
If you don't want to mess with the VMIO stuff, increasing the size of the
buffer cache as a workaround will help, but not as well as the VMIO fix.
It doesn't work as well because the buffer cache has high turnover and
the directory data will still be lost even if B_MALLOC space has not been
exhausted. I do not know what the memory impact of the constant scanning
would be w/ the VMIO fix -- probably pretty wasteful (for this situation
John's complaints are certainly real). But FreeFall's problem has always
been I/O rather then memory. Given the choice between I/O and memory,
it's always cheaper to buy more memory. I think the VMIO fix would be
a win despite the memory.
At a rough guess, there are 2800 directories in the CVS tree. Assuming 4K
per directory you wind up with around 11 MBytes worth of directory data.
Not a very high price to pay if you ask me. Quite reasonable.
-Matt
Matthew Dillon
<dillon@backplane.com>
: John Polstra jdp@polstra.com
: John D. Polstra & Co., Inc. Seattle, Washington USA
: "Self-interest is the aphrodisiac of belief." -- James V. DeLong
:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904192330.QAA91277>