mfs and buildworlds on the SunFire x4600

Mars G. Miro marsgmiro at gmail.com
Mon May 7 21:47:37 UTC 2007


On 5/8/07, Oliver Fromme <olli at lurza.secnetix.de> wrote:
> 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.
>

oh. I didnt quite get that.. apologies ;-)

>  > > 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?
>

as i've mentioned in my original email, does mfs speed up I/O stuff ?
there's been a lot of threads in teh past that a buildworld on mfs
increases speed --- tho it might not be the appropriate test for
high-end machines (speaking of w/c I just gots a T2000).

there's prolly other appropriate apps/tools for mfs-testing ...

> 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:
>

jahh, i know about these


> 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
>

Thanks ;-)


> --
> 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)
>


cheers
mars


More information about the freebsd-stable mailing list