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>