Nik Clayton wrote:
>
> On Fri, Mar 02, 2001 at 11:34:19PM +0900, Daniel C. Sobral wrote:
> > Here is the order suggested and the why:
> >
> > 1) make buildworld -- because the new kernel may depend on new tools
> > (config(8) is a common example, but no the only one).
> > 2) make buildkernel -- some programs may depend on new syscalls, so
> > build the kernel before installing the world.
> > 3) make installkernel -- install a new kernel (the copy of the old one
> > is preserved)
> > 4) reboot single user -- make sure the new kernel works
> > 5) mount filesystems, make installworld -- install the rest of the world
> > 6) mergemaster -- update /etc -- the new userland tools may require new
> > /etc scripts and configuration files.
>
> I think the attached diff to the Handbook brings it up to date with
> reality. I've also attached the generated HTML file, for those of you
> that don't want to build the docs. Comments?
Yes, there are several things that I think are basically wrong. On the
-j4 option, what was -current is now 4.0-release or later. On a fast
uniprocessor system, using -j4 on the make actually causes the
buildworld to run 10% or more longer by the clock. Your user and
system time may be shorter but the build takes forever. You are adding
overhead to access I/O that the HD's can't provide and the cpu is left
in an idle state waiting for I/O. This becomes especially true on
large single HD's. Turning on softupdates helps. I have a AMD
Thunderbird 900 with 256MB of PC-133 memory that I tried various
combinations on. I added ATA-100 HD's until I had reasonable build
times. I eventually ended up with 3 and had each on its own
controller. I haven't tried fast scsi yet but I think the majority of
the new users are building systems around IDE drives and you can see
the slowdown when you use -jx with x >= 2. It isn't bad for people
running setiathome because it will continue to use 40% or more of the
cpu and doesn't interfere. When the percentage reported by time goes
over 100%, which it can for multiprocessor systems, setiathome didn't
get much time. That data also wasn't included in my table.
The only system that can use -j4 is a dual headed system (2-P-III
866's with 256MB of PC-133) with the source on a 2-HD HPT-370 raid-0
array. The system has 3-30GB Maxtor ATA-100 HD's all on different
controllers. The variation in build time ran from 1:21 to 34 minutes
with softupdates and /usr/src on the raid-0 array. If I tee the output
from the build to a file, it only slows the build down to 35:xx
minutes. Some entries from my build times log are:
buildworld, softupdates, 1-HD
1597.238u 629.123s 47:52.34 77.5% 1227+1393k 42713+11617io
1575pf+0w
raid-0 for /usr/obj but no softupdates.
1599.347u 628.302s 1:21:36.28 45.4% 1230+1395k 44554+138574io
1828pf+0w
raid-0 (64k) for /usr/src, -j4, and softupdates for everything but /
1655.441u 730.090s 34:16.34 116.0% 1210+1380k 47507+3918io
1881pf+0w
make buildworld with tee'ed logging and current setup from above
1665.892u 702.004s 35:14.42 111.9% 1211+1387k 51575+4140io
1918pf+0
The chflag noschg isn't needed on 4.2. I don't know when that was
changed but you don't have to use it to rm -rf * files in /usr/obj. Of
course, if you have a kern_secure level set in 4.2, you can't noschg
anything from multi-user mode and the installkernel will die trying to
mv the kernel's around. You have to be running in single user mode to
get around the kern_secure level setting.
Kent
>
> N
> --
> FreeBSD: The Power to Serve http://www.freebsd.org/
> FreeBSD Documentation Project http://www.freebsd.org/docproj/
>
> --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 ---
>
> ----------------------------------------------------------------------
> Name: makeworld.html
> makeworld.html Type: Hypertext Markup Language (text/html)
> Encoding: quoted-printable
>
> Name: mw.diff
> mw.diff Type: Plain Text (text/plain)
> Encoding: quoted-printable
>
> Part 1.2Type: application/pgp-signature
--
Kent Stewart
Richland, WA
mailto:[EMAIL PROTECTED]
http://kstewart.urx.com/kstewart/index.html
FreeBSD News http://daily.daemonnews.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
