From owner-freebsd-stable@FreeBSD.ORG Fri Jun 6 19:52:27 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCBCD106564A for ; Fri, 6 Jun 2008 19:52:27 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 643828FC3C for ; Fri, 6 Jun 2008 19:52:27 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m56JqVBb003055; Fri, 6 Jun 2008 14:52:31 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m56JqVen003054; Fri, 6 Jun 2008 14:52:31 -0500 (CDT) (envelope-from brooks) Date: Fri, 6 Jun 2008 14:52:31 -0500 From: Brooks Davis To: Royce Williams Message-ID: <20080606195231.GB2438@lor.one-eyed-alien.net> References: <9B7FE91B-9C2E-4732-866C-930AC6022A40@netconsonance.com> <4846D849.2090005@FreeBSD.org> <20080604204325.GD4701@lava.net> <702FA4B9-8CEE-4C9D-86A8-157CA1E69BD7@khera.org> <1212768942.6066.20.camel@tremelay> <48499129.4090704@alaska.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OwLcNYc0lM97+oe1" Content-Disposition: inline In-Reply-To: <48499129.4090704@alaska.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Fri, 06 Jun 2008 14:52:31 -0500 (CDT) Cc: FreeBSD Stable Subject: Re: 6.3 stability and freebsd-update (was: Re: challenge: end of life for 6.2 is premature with buggy 6.3) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 19:52:27 -0000 --OwLcNYc0lM97+oe1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 06, 2008 at 11:34:01AM -0800, Royce Williams wrote: > >> On Jun 4, 2008, at 4:43 PM, Clifton Royston wrote: > >> > >>> Speaking just for myself, I'd love to get a general response from > >>> people who have run servers on both as to whether 6.3 is on average > >>> more stable than 6.2. I really haven't gotten any clear impression as >=20 > 6.3 has been stable for me. I've been running since April on DL380 > G2, Dell 2450, Supermicro 5015M-MF and 5015T-PR, and some older Intel > 815E boards. My bge(4) NICs are detected as Broadcom BCM5703 A2 and > BCM5704 A2, with no issues. Running gmirror with no issues. >=20 > Someone mentioned freebsd-update earlier in the thread. I'd like to > take a moment to plug it, since making it easy to move to 6.3 seems > topical. I got a little long-winded, so here's an executive summary: >=20 > freebsd-update is good; business case for more hardware; updating in > 'hybrid' mode with custom kernels and stock userland; using kernel > config 'includes' to save additional effort. >=20 >=20 > I prefer freebsd-update over the buildworld and then > installworld-over-NFS routine, centralized rsyncs, or anything else. > I used freebsd-update to uplift the systems above, and also just > bumped sixteen more from 6.2. Worked like a charm. Its 'rollback' > option is also very handy, for obvious reasons. >=20 > Based on how much time I save with freebsd-update, I can make a > business case for buying another box for a farm, rather than rolling > my own kernels and eking out xx% of additional performance. Once ULE > gets into 7.x-RELEASE, I probably won't even have to do that. >=20 > For systems that require a custom kernel, we still patch everything > else with freebsd-update. When freebsd-update detects the non-stock > kernel, it warns you to install a kernel from the target release. If > that scares you, you can swap in a stock kernel from the current > release (saved off, or from the release media or FTP) and then > upgrade. When finished, save off the new stock kernel for future > upgrades, and then rebuild your custom kernel. (Anybody else doing > anything like this, or something better?) Alternativly, you can edit freebsd-update.conf and tell it to not update yo= ur kernel on those machines. You can also exclude particular files. We use this to keep from updating libc directly on some machines where we're using modified RPC timings to improve NIS performance in the face of occataionl packet loss. -- Brooks > GENERIC or PAE or whatever). If you use nocpu, nooptions, > nomakeoptions, nodevice etc. to turn off what you don't need, your > config is reduced to a 'diff' of sorts against the stock config. Our > kernel configs are now ~17 lines, can be grokked at a glance, and > should change little from release to release. Here's a stub of an > example that uses most of the knobs: >=20 > include SMP # Inherit SMP (which inherits GENERIC). >=20 > nocpu I486_CPU # Disable old CPU support; see tuning(7). > nocpu I586_CPU > ident SMP-GENERIC_CUSTOM_FOO # Inherit ident, custom name. >=20 > nomakeoption DEBUG # Do not build with gdb(1) debug symbols. >=20 > nooptions SCHED_4BSD # Do not use the 4BSD scheduler; > options SCHED_ULE # use ULE schedule instead. >=20 > # ALTQ support > options ALTQ > options ALTQ_CBQ # Class Bases Queuing (CBQ) > options ALTQ_RED # Random Early Detection (RED) > options ALTQ_RIO # RED In/Out > options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) > options ALTQ_PRIQ # Priority Queuing (PRIQ) > options ALTQ_NOPCC # Required for SMP build >=20 > # Devices for pf > device pf # PF > device pflog # pflog > device pfsync # pfsync >=20 >=20 > Use 'nodevice' to turn off devices worth leaving out, but only as many > as are worth the effort. >=20 > If you haven't already considered freebsd-update, either for the whole > system or just userland, I highly recommend it. These days, the gain > has to be pretty significant for me to want to go back to making > world. For our PXE installs using custom install.cfg, we can go from > bare metal to a fully patched vanilla system in four minutes on modern > hardware! The novelty of that still hasn't worn off. :-) >=20 > It's more efficient (and probably safer?) to use freebsd-update > against a binary install rather than against local compilation. And > if you're bumping major versions (6.x -> 7.x), you still have to > rebuild your ports. But try it in your lab or for your next > deployment. You can easily convert a freebsd-updated system to a > makeworld system, if necessary. >=20 > And thanks again, Colin! >=20 > Royce >=20 > --=20 > Royce D. Williams - http://royce.ws/ > Inspiration exists, but it has to find us working. - Pablo Picasso > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >=20 --OwLcNYc0lM97+oe1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFISZV+XY6L6fI4GtQRAvRGAKCgXnmIz5+YGHaC4loLe2GiJYw6QQCghMlF b4SKcYZfLCe5ebfuKQrm/RI= =qlx3 -----END PGP SIGNATURE----- --OwLcNYc0lM97+oe1--