Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Jun 2008 14:52:31 -0500
From:      Brooks Davis <brooks@freebsd.org>
To:        Royce Williams <royce@alaska.net>
Cc:        FreeBSD Stable <freebsd-stable@freebsd.org>
Subject:   Re: 6.3 stability and freebsd-update (was: Re: challenge: end of life for 6.2 is premature with buggy 6.3)
Message-ID:  <20080606195231.GB2438@lor.one-eyed-alien.net>
In-Reply-To: <48499129.4090704@alaska.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>

next in thread | previous in thread | raw e-mail | index | archive | help

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080606195231.GB2438>