From owner-freebsd-current Thu Apr 27 18:32:32 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 636A337B934 for ; Thu, 27 Apr 2000 18:32:30 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA07593; Thu, 27 Apr 2000 18:32:24 -0700 (PDT) (envelope-from dillon) Date: Thu, 27 Apr 2000 18:32:24 -0700 (PDT) From: Matthew Dillon Message-Id: <200004280132.SAA07593@apollo.backplane.com> To: Carl Makin Cc: freebsd-current@FreeBSD.ORG Subject: Re: Support for large mfs References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message