xfs
[Top] [All Lists]

Re: A short digression on FOSS (Re: understanding speculative preallocat

To: Jay Ashworth <jra@xxxxxxxxxxx>
Subject: Re: A short digression on FOSS (Re: understanding speculative preallocation)
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Mon, 29 Jul 2013 12:05:55 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <15781090.2540.1375111802121.JavaMail.root@xxxxxxxxxxxxxxxxxxxx>
References: <15781090.2540.1375111802121.JavaMail.root@xxxxxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
On 7/29/13 10:30 AM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Eric Sandeen" <sandeen@xxxxxxxxxxx>
> 
>>>> From: "Dave Chinner" <david@xxxxxxxxxxxxx>
>>>
>>>> The "version" of XFS that you are running is that of the
>>>> kernel you are running. i.e. 2.6.32-279.x.y or 2.6.32-358.x.y.
>>>
>>> Those aren't kernel versions; those are kernel *package* versions.
>>
>> Those are RHEL kernel version numbers, which 100% uniquely identify
>> the code contained in those kernels.
> 
> So how, Eric, would that help, say, SuSE users -- 

Well, it doesn't... SuSE helps SuSE users.  And I'm not being glib,
that's just how it works.

> which the XFS website makes 
> special note to point out that there's a specific agreement in place to 
> support.  Even SLES users vice openSUSE, though the XFS.org website doesn't 
> make that distinction.

xfs.org is a public wiki run by a 3rd party, so I can't speak to the accuracy
of statements made about support agreements between SGI & SuSE, if any.

So I guess I have no useful insight there.

> I'm sticking with "those are kernel package versions", and I was yelled
> at the other day because I was interested in things that weren't "mainline
> kernel versions".  RHEL kernels are the *best available example* of "not
> a mainline kernel version", so I find these conflicting reports most
> conflicting.

You're welcome to be interested all you want, but availability of support
from either SGI (not related to CentOS at all), upstream (focused on new work,
not older distros), or Red Hat (who sells support, vs. gives it away, in
order to pay the people to keep maintaining the distro that CentOS is
more than welcome to pick up, rebuild, & ship, and support or not as *they* 
see fit).

You'll find that you usually get very good support for XFS issues & questions
related to near-current mainline kernels.  But people who can spend time
& effort supporting free distros containing custom codebases are going
to be few & far between.

The closer you get to mainline, the more willing & able the developers
will be to help you out.  The further you get into custom distro kernels,
the more it becomes the responsibility of that distro - CentOS, in your case,
and they pretty explicitly tell you what you can expect for support from
them.

I'm not trying to be flippant or glib or antagonistic here, that's just
the way things are structured; you chose CentOS, and "CentOS is designed for
people who need an enterprise class OS without the cost or support of
the prominent North American Enterprise Linux vendor."

>>> Kernel versions are w.x.y or w.x.y.z.
>>
>> ^Upstream.
> 
> "Mainline".  Which was not my choice of term.

(Ok, mainline; I was just differentiating between RHEL & Linux.)

-Eric


> Cheers,
> -- jra
> 

<Prev in Thread] Current Thread [Next in Thread>