Date: Fri, 06 Jun 2008 11:34:01 -0800 From: Royce Williams <royce@alaska.net> To: FreeBSD Stable <freebsd-stable@freebsd.org> Subject: 6.3 stability and freebsd-update (was: Re: challenge: end of life for 6.2 is premature with buggy 6.3) Message-ID: <48499129.4090704@alaska.net> In-Reply-To: <1212768942.6066.20.camel@tremelay> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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 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. 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: 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. 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. 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. 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?) I also recommend starting your kernel config with 'include SMP' (or 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: include SMP # Inherit SMP (which inherits GENERIC). nocpu I486_CPU # Disable old CPU support; see tuning(7). nocpu I586_CPU ident SMP-GENERIC_CUSTOM_FOO # Inherit ident, custom name. nomakeoption DEBUG # Do not build with gdb(1) debug symbols. nooptions SCHED_4BSD # Do not use the 4BSD scheduler; options SCHED_ULE # use ULE schedule instead. # 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 # Devices for pf device pf # PF device pflog # pflog device pfsync # pfsync Use 'nodevice' to turn off devices worth leaving out, but only as many as are worth the effort. 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. :-) 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. And thanks again, Colin! Royce -- Royce D. Williams - http://royce.ws/ Inspiration exists, but it has to find us working. - Pablo Picasso
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48499129.4090704>