Re: kernel choices?

On Wed, 2003-07-16 at 04:36, adam morley wrote:
> All,
> 
> I've been vacilating on what kernel to pick for a production server. 
> I've basically decided I have to update anything (even vanilla) as the
> raid card, scsi card and network cards I'll be using have newer
> drivers released (not to mention the qlogic fibre channel cards), but
> where to start?  I thought I'd start with gs-sources, but it looks
> like its using a prerelease kernel.

Indeed. I would definitely not recommend gs-sources for such purposes.

> Others suggested I use gentoo-sources, but its optimization goals
> don't seem well suited to a headless server environment, but more to a

There's nothing wrong with optimisation, but it has to be balanced
against stability, security and flexibility.

> multipurpose system.  The hardended sources also seemed like a good
> pick, but they're all masked, so I don't want to get too near them
> with a production server.

I agree, the hardened-sources look promising. To be honest, I wouldn't
read /too /far into whether a given set of sources is masked or not. By
that benchmark, I wonder if anything other than vanilla-sources should
be unmasked at all, yet vanilla (at least 2.4.20) has some serious flaws
...

> Is my best bet just to start with vanilla and add from there, or is

No, personally I wouldn't recommend that unless the level of extra
features you require are very few. There are other people doing this
sort of thing very competently, and unless one fancies oneself a genuine
kernel hacker I would avoid this route!

> there a better route?  What do you folks do?  In the event you do
> provide a suggestion, please give me a feel for the use of the system,

OK, to cut to the chase - I use the WOLK kernel, specifically
2.4.20-wolk4.3s (Working Overloaded Linux Kernel Server Edition). The
name is derived from a decent patchset by the name of FOLK, but it
became unmaintained. In actual fact, I have used WOLK for some time and,
since then, no other 2.4 patchset has yet convinced me that there is any
reason to switch on my server /and/ my workstations.

The guy who maintains WOLK is _very_ smart indeed. If any evidence is
needed of that, it was he who convinced Andrew Morton (not without a
good deal of resistance) that there was a problem with deadlocks/IO
stalls unresolved since 2.4.19, which was resolved in 2.4.21 amid much
hype. It was in fact the WOLK author who diagnosed and corrected the
issue, and Mr Morton later submitted the fix under his own name!

The WOLK patch, as the name implies, is a very big patch indeed. Just
some of the highlights are:

 * Rik van Riel's RMAP virtual machine 1.5j with various tweaks/fixes
 * grsecurity 1.9.9h
 * Linux Trustees ACLs v2.10
 * Tuned O(1) scheduler implementation
 * Server scheduler tweaks
 * Memory Pools support (to prevent memory exhaustion when dealing with
high stress loads)
 * OOM (Out-Of-Memory) killer
 * Bugfixed low-latency implementation
 * Virtual Servers (ctx) support
 * ReiserFS speedups
 * All known filesystem/security fixes including TCP routing cache DoS
flaw, ptrace flaw and a nasty bug which causes problems when using md
RAID with ReiserFS filesystem.
 * SCSI monitoring
 * EVMS
 * Device Mapper (for LVM2 support a la 2.5/2.6)
 * XFS (from up-to-date CVS checkout)
 * CryptoAPI
 * FreeS/WAN 1.99.7.3 (note that 2.x still has some features which are
not implemented)
 * Plenty of extra/updated network/SCSI card drivers

Of course if you don't need any particular feature then you are under no
obligation to enable it (with the exception of O(1) and low-latency).

Aside from this, there are a lot of fixes for silly 2.4.20 bugs. In
actual fact, I trust this kernel more than I would the current 2.4.21
vanilla kernel. More here (the ChangeLog in the second link gives an
interesting insight into how capably this patchset is maintained):

http://sourceforge.net/forum/forum.php?forum_id=272768
http://sourceforge.net/project/shownotes.php?group_id=49048&release_id=127402

> what the SLAs are, etc.  Ie: the system being built is a two way xeon
> with raid'd boot drives, failover qlogic fibre cards to a redundant

Drivers are present for Qlogic FAS/ISP/ISP FC/QLA 1280/QLA 2xxx FC
cards.

> fcal array, and there's a cold spare in the next rack, so the goal is
> decent enough uptime, but we're not talking four/five nines or

With regard to uptime, I have experienced crashes with only one release
in WOLK (I believe that was the 3rd release candidate for 4.0s). That
was rectified immediately in the next release candidate, and I have used
every release since. I am now running the "official" 4.3s release and I
have no regrets - it is absolutely rock solid. Some of the guys I've
spoken to in the wolk channel are running it on some seriously heavy
iron too, so I know it gets tested in an appropriate context (I use a
humble Compaq Proliant ML350 myself).

If you feel like giving this kernel a spin, then you should realise that
there is a snag. The ebuild is totally unmaintained at present (hence
completely out-of-date). Patching a tree is not difficult though. First
you need to get the following files from here:

http://sourceforge.net/project/showfiles.php?group_id=49048&release_id=127402

 * linux-2.4.20-wolk4.0s.patch.bz2
 * linux-2.4.20-wolk4.0s-to-4.1s.patch.bz2
 * linux-2.4.20-wolk4.1s-to-4.2s.patch.bz2
 * linux-2.4.20-wolk4.2s-to-4.3s.patch.bz2

Now, assuming you have no 2.4.20 vanilla sources in place and that the
2.4.20 vanilla sources tarball and wolk patches are present in your
distfiles directory:

cd /usr/src
tar -xjvf /usr/portage/distfiles/linux-2.4.20.tar.bz2
mv linux-2.4.20 linux-2.4.20-wolk4.3s
ln -sf linux-2.4.20-wolk4.3s linux
cd linux
bzcat /usr/portage/distfiles/linux-2.4.20-wolk4.0s.patch.bz2 | patch -p1
bzcat /usr/portage/distfiles/linux-2.4.20-wolk4.0s-to-4.1s.patch.bz2 |
patch -p1
bzcat /usr/portage/distfiles/linux-2.4.20-wolk4.1s-to-4.2s.patch.bz2 |
patch -p1
bzcat /usr/portage/distfiles/linux-2.4.20-wolk4.2s-to-4.3s.patch.bz2 |
patch -p1

That's all there is too it. You may wish to ensure that the following
line is in your /var/cache/edb/virtuals file, so that Portage won't try
to drag in gentoo-sources when emerging certain things.

 virtual/linux-sources sys-kernel/vanilla-sources

Or use the emerge inject feature to satisfy Portage's need to believe
that some kernel sources were installed via an ebuild.

In any case, do let us know what your eventual decision is. I would be
interested to see how your experiences turn out!

Regards,

--Kerin Millar (kerframil)


--
[email protected] mailing list