mfs and buildworlds on the SunFire x4600

Oliver Fromme olli at lurza.secnetix.de
Mon May 7 21:30:06 UTC 2007


I took the liberty to s/da/the/g in your mail.

Mars G. Miro wrote:
 > Oliver Fromme wrote:
 > > Mars G. Miro wrote:
 > > > Actually, it's not about having to finish building the world in the
 > > > smallest amount of time, it's about whether mfs would really speed
 > > > things up...
 > > 
 > > I've made similar tests in the past, and my conclusion is
 > > that it's not worth it.
 > > 
 > > Using a memory disk for /usr/obj doesn't make much sense,
 > > because soft-updates decouples the physical writes pretty
 > 
 > as i've mentioned in my original email, the mfs's were created w/
 > softupdates turned off

No, I'm not talking about the memory disks.  It's rather
irrelevant whether you use soft-updates on them or not.

What I meant is this:  If you use a normal disk (not memory
disk) for /usr/obj, soft-updates will decouple the writes
from the compilation process, so the buildworld will be
less I/O-bound.  With good hardware it should be just as
fast as a memory disk.  Therefore it does not make sense
to use a memory disk for /usr/obj, IMHO.

 > > well from the build process.  On the other hand, using a
 > > memory disk for /usr/src _might_ help a little, but it
 > > depends on a lot of things.  Especially if you have a
 > 
 > again, both /usr/src and /usr/obj were mfs, and even async, noatime

Doesn't matter for memory disks.

 > > speedy I/O system and plenty of RAM (so all of the files
 > > can be cached) and /usr/src is mounted with the "noatime"
 > > option, the difference is very small.
 > 
 > as Kris mentioned, a buildworld isnt prolly the appropriate test for
 > mfs,

That's correct.

 > as for the chrooted /usr or the buildkernel tests, I havent really
 > tried them --- will try to do so and report back when i get the time
 > ...

By the way, what are you actually trying to do?  What is
your goal?  Do you need to reduce the buildworld time?

In that case, excluding some things that you don't need
(via "NO_*" variables in /etc/make.conf) will probably
give much better results than trying to play with mfs.
For example, on most of my machines, I have the following
in /etc/make.conf, reducing buildworld times noticeably:

NO_KERBEROS=yes
NO_BLUETOOTH=yes
NO_FORTRAN=yes
NO_I4B=yes
NO_ATM=yes
NO_VINUM=yes
NO_OBJC=yes
NO_SHAREDOCS=yes
NO_PROFILE=yes

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"Clear perl code is better than unclear awk code; but NOTHING
comes close to unclear perl code"  (taken from comp.lang.awk FAQ)


More information about the freebsd-stable mailing list