Re: Best suiting OS - Mailing list pgsql-performance

On Sun, 4 Oct 2009, Mark Mielke wrote:

> I can show you tickets where RedHat has specifically state they *will
> not* update the kernel to better support new hardware, for fear of
> breaking support for older hardware.

There are two reasonable paths you'll find in the Open Source world, which
mirror the larger industry at large:

1) Branch a stable release rarely.  Sit on it for a while without changing
anything before release.  Backport only critical stuff (important bug
fixes) into the stable version once it's out there.  Support that version
for years.  Examples of this model include RedHat and PostgreSQL, albeit
with the latter having a much more regular release schedule than most
"long-term release" pieces of software.

2) Branch a stable release often.  Push it out the door with fairly recent
components.  Backport little, because a new release is coming out the door
soon enough anyway.  It's impossible for this model to backport as much as
(1), because they have so many more releases to handle, and there's no
pressure to do so because "upgrade to the latest release to fix" is
usually an options.  Examples of this model include the Linux kernel
proper and Ubuntu.

My personal belief is that (2) never leads to stable software, and that
for the complexity level of the projects I follow you're lucky you can get
a stable version of one piece of software if you focus on it about every
year.  Once every two years would be better, because as you correctly note
it takes about that long for many hardware drivers to go from cutting-edge
to old, and that would give less disruption to admins.

That is unfortunately both more aggressive than the "long-term release"
stable versions provided by RedHat and less than the hyper-aggressive
schedules you'll find in Ubuntu and Fedora.  It does happen to be very
close to the PostgreSQL stable release frequency though:

8.0 2005-01-19
8.1 2005-11-08
8.2 2006-12-05
8.3 2008-02-04
8.4 2009-07-01

RedHat does a commendable job of backporting way more stuff than anybody
else I'm aware of.  The SATA issues you mention are actually a worst-case
for their development model.  The big SATA switch-over with "Parallel PATA
merge" happened in 2.6.19.  My recollection is that this was such a mess
at first is basically forced RedHat to release RHEL5 with 2.6.18, as there
wasn't expected to be a stable ATA stack from the resulting chaos for a
few releases they could use; anecdotally, I didn't find Linux
re-stabilized until between 2.6.20 and 2.6.22, depending on your hardware.

I contrast this with Ubuntu, which I can't accept as a server because
nothing I run into *ever* gets backported.  I know they backport
something, because I see the changelogs, but never what I run into.  I
encounter a bug or two in ever new Ubuntu release that makes life
difficult for me, and in every case so far the "resolution" was "fixed in
<next letter>".  In two of those cases I recall I saw the same bug fix
(from an upstream package) was backported into RHEL.

> All 7 of the machines I installed RHEL 5.3 on *failed* to detect the
> SATA controller, and the install process completed at 2 Mbyte/s. After
> the machines were up, I discovered the issue is a known issue, and that
> RedHat would not patch the problem, but instead suggested a change to
> grub.conf. Is this stable?

With all due respect, this was operator error on your part.  Buying the
hardware and then guessing that everything will work out fine with the OS
install isn't ever a path to stable either.  I (and every other person who
deals regularly with RHEL on increasingly new hardware) could have told
you this was going to be a disaster, that you don't try to provision a
server using native SATA with unknown compatibility on that OS.  I don't
have this problem (for the database servers at work at least--suffered
through it plenty with random white boxes).  I buy from a vendor who
figures this out and old sells me stuff that works on RHEL.  You have a
larger process problem you can't blame on the software.

> They finally back-ported FUSE - but did you know their 2.6.18 kernel has
> something like 3000 patches that they maintain against it? Does this not
> sound insane? How do you provide effective support for a kernel that has
> 3000 back ported patches against it?

How exactly is this any different from "effective support" for the kernel
at large, which integrates way more patches than that between releases?
I see RedHat as having a much smaller set of patches to manage, which is
one reason their releases are more stable than "pick a random kernel
release".

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD