Date: Sat, 8 Dec 2001 20:58:46 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Doug Ambrisko <ambrisko@ambrisko.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems Message-ID: <200112090458.fB94wkW35035@apollo.backplane.com> References: <200112090414.fB94Eoa19371@ambrisko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:| no performance issues involved with people using /tmp files that requires :| MFS or MD. It's an unnecessary waste of memory and an unnecessary burden :| on our VM system. : :Unless you want a cvs pserver to run fast! I did some benchmarks a while :back (port 4.2 I think) in which I had /tmp on soft-updates. It was :a little faster on "cvs co freebsd" for example. CVS pserver was running :on a dedicated machine and the CVS client was on another. Switched to Try it with softupdates turned on. Still, I'd expect MFS to be faster even against softupdates, but that doesn't mean its a good idea to create an MFS /tmp by default. At BEST we wound up putting the sendmail domain cache under MFS for similar reasons, but we never put /tmp under MFS (on any machine)... physical ram was far too precious to waste on /tmp. :MFS made a significant improvement. I don't have the number anymore :(changed employers). I think the issue here is that CVS on the pserver :checks out a sparse tree of the meta data for the each directory :... : :One thing I didn't try was mounting /tmp as async and maybe noatime. :That might be an interesting thing to try. : :Doug A. : -Matt Matthew Dillon <dillon@backplane.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112090458.fB94wkW35035>