Date: Thu, 27 Apr 2000 18:32:24 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Carl Makin <carl@xena.IPAustralia.gov.au> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Support for large mfs Message-ID: <200004280132.SAA07593@apollo.backplane.com> References: <Pine.BSF.4.21.0004281058490.37264-100000@newton.aipo.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
:Hi Matthew,
:
:On Thu, 27 Apr 2000, Matthew Dillon wrote:
:
:> I can't imagine why MFS would perform better... it shouldn't, every
:> block is stored in system memory *TWICE* (once in the VM cache, and
:> once in the mfs process's address space). If you have enough system
:
:I've been running a MFS /tmp dir since around 2.2.4, are you now saying
:that it would be better (under 4.0-STABLE or CURRENT) to run a swap backed
:vnode fs?
:
:Carl.
With a softupdates /tmp, the only thing MFS will save you are the
write-behind disk writes on large files. The cost to using MFS is that
every disk block in an MFS filesystem is in main memory twice. If you
do anything significant in your /tmp this will strain the VM system.
In general, an MFS /tmp does not give you enough of an advantage to be
worth it. I would go with a normal UFS /tmp with softupdates enabled.
A Swap-backed VN /tmp will work as well, but keep in mind that the
sector size is 4K and you should use the appropriate options to
vnconfig to pre-reserve the swap space so performance does not degrade
from fragmentation.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004280132.SAA07593>