Re: kernel choices?

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is one of the most interesting threads to date on this list. Thanks ve=
ry=20
much for the posts.


On Wednesday 16 July 2003 07:14, Kerin Millar wrote:
> 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=3D272768
> http://sourceforge.net/project/shownotes.php?group_id=3D49048&release_id=
=3D1274
>02
>
> > 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=3D49048&release_id=
=3D1274
>02
>
>  * 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

=2D --=20
Ken=20
[email protected]
//IRC - antifa
=2D -----------------------------------------------------------------
pgp fingerprint 2D6D 67D1 1600 04E0 4AF7 BA7E 26A5 4189 9228 1585
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD4DBQE/FaP3JqVBiZIoFYURAkMlAJiPA2ye0LAr1Ybg/0Rou56lD4caAJ4g7hs0
kiS3znckCq4fjHKGbrjuFQ=3D=3D
=3Dm5pu
=2D----END PGP SIGNATURE-----


--
[email protected] mailing list