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