[Ocfs2-users] ocfs2 custom builds

Thu Jul 19 10:52:32 PDT 2007

Alexei_Roudnev wrote:
> In reality, THE ONLY working combinations of OCFSv2 and Linux which we
> can use in production without full, from ground zero, testing, are
> SLES and UL/EL coming with the system (not compiled by us but taken
> from the vendor) OR (the last chance) compiled in Oracle and takesn as
> an rpm.
>
Can't say I agree here. I have compiled and used ocfs2 for quite a while
in production and have only run into the problem where a node's
heartbeat times out > 10 seconds during heavy load.

> All other combinations are extremely experimental by nature - they can
> work, but you must test everything including fencing, heavy load and
> so on.
How so? So you believe that the distro has FULLY tested every possible
combination of its drivers? If that were the case, why do they provide
newer versions of the packages in the first place. And when they do
provide a new package, you think they test that to the level you
suggested we need to qualify ocfs2 as stable? How many packages have you
seen in a distro that were provided and have WELL KNOWN bugs? I can't
count the number. I have even seen distros release a new version KNOWING
that many huge bugs have not been fixed and I mean documented bugs.

The source for a module should be just that. How does it differ than
when it is patched into the kernel by the kernel devs? It should not be
different or why provide source in the first place. We are talking about
a driver and only a driver. Once again, I believe upgrading the whole
kernel  just to upgrade one  of  the thousands of drivers  is just
overkill.
>
> Full testing is not realistic except if you are a server's farm and
> can spend time (and possible money) to set up test environment and run
> few days - 1 week tests each time when anything change.
>
> It's not because OCFS team and / or Linux vendors tests everything (as
> I can see, they don't test much) - it's because when you use prepacked
> configuration, other users use exactly the same software so your
> installation base is bigh enough to know about problems before you hit
> these problems. If you compine your own kernel or modules, you have
> not this benefit.
>
Exactly. Why do you trust their patched ocfs2 kernel over one that
simply uses a custom compiled ocfs2 driver if they don't test that in
depth?

> PS> I keep avoiding ANY custom modules or kernels in all cases when it
> is possible - and for now, these are 99.99% of all installations. Any
> 'additional' compilation (even if it is something harmless) drops
> overall reliability of the system (in a long term - when we run
> upgrade in 2 years for example) so much that it usually overweight any
> benefits from such compilation. But if I had 1,000 simular servers in
> a server's farm, I should consider custom kernels after settiong up
> test environment and procedures.
>
This MAY be true, but how many times have you needed a newer package
only to find out the distro has not supplied it or needed a driver that
they have not compiled in?  Are we to be at the mercy of the vendor for
every single component of the server we maintain? Just look at how many
packages are outdated in the distro you are using and tell me  that
using  more recent versions of whatever software is outdated make the
overall distro less reliable. Maybe it makes more reliable.

> ----- Original Message ----- From: "Randy Ramsdell"
> <rramsdell at livedatagroup.com>
> To: "ocfs2-users" <ocfs2-users at oss.oracle.com>
> Sent: Thursday, July 19, 2007 5:57 AM
> Subject: Re: [Ocfs2-users] ocfs2 custom builds
>
>
>> Sunil Mushran wrote:
>>> You do realize that the kernel is constantly changing and
>>> it is not possible to keep one version of any component
>>> compatible with the kernel without changing that too.
>>>
>> Ok, you already do that correct? Why prevent end users from compiling
>> your source on the later kernels ( the ones that are compatible). From
>> my original post, I was referring to the fact that it says we will not
>> be able to compile the source on kernels it is compatible with.
>>
>>> The only way we can keep the fs compatible with the kernel
>>> is to keep updating the fs too. The version of the fs in the
>>> kernel tree tracks the kernel.
>> Then the source should be compatible too correct?
>>>
>>> The 1.2 tree is meant to work with few kernels only. As in,
>>> EL and SLES. That's it.
>>>
>> Interesting. So you are saying that 1.2 only works with heavily patched
>> kernels for only 2 distros? I just don't get that. If fact, I haven't
>> too much of an issue so far compiling on different distros as long as I
>> am able to find patches to your source that haven't been released or
>> aren't contained within the provided source.
>>> Randy Ramsdell wrote:
>>>> Sunil Mushran wrote:
>>>>
>>>>> What's wrong with using ocfs2 bundled with the kernel?
>>>>>
>>>>>
>>>>
>>>> Top posting argh.
>>>>
>>>> I find that upgrading a "driver" by using a completely different
>>>> kernel
>>>> a little overkill. What happens when we need a better ocfs2 driver and
>>>> the distro only has ocfs2 three versions back? Well, we build from
>>>> source, and don't have to worry about downlading the latest kernel
>>>> release, which doesn't include the patches that the distro has
>>>> included
>>>> which are sometimes needed. To upgrade to a recent version of ocfs2
>>>> on a
>>>> distro that uses an old version requires that we abandon the distro
>>>> kernel, download pristine kernel source, and compile/install from
>>>> there.
>>>> Once again this seems way overkill and somehow microsoft'ish. We
>>>> need a
>>>> driver and only the driver sometimes. This same problem exists with
>>>> other software packages, such as spam, email virus detection or
>>>> filesystem drivers that need to be upgraded more frequently than
>>>> what I
>>>> see currrently with most package based distros. As an example, the
>>>> latest version we have currently available in the kernels we use is
>>>> v1.2.3, but we run v1.2.5 since I compile and create rpms for them. I
>>>> would really like to see the source remain compilable just in case we
>>>> cannot upgrade the complete OS version or distro to one that
>>>> contains a
>>>> more recent ocfs2 version.
>>>>
>>>> Thanks,
>>>> Randy Ramsdell
>>>>
>>>>
>>>>> Randy Ramsdell wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> >From the main ocfs2 site, I read this.
>>>>>>
>>>>>> <quote>
>>>>>> For users building from OCFS2 1.2.x tarballs
>>>>>> <http://oss.oracle.com/projects/ocfs2/files/source/v1.2/> with
>>>>>> kernels
>>>>>> 2.6.14 or later, use the following make command:
>>>>>>
>>>>>>     make GENERIC_DELETE_INODE_NOT_TRUNCATES=1
>>>>>>
>>>>>> NOTE: OCFS2 1.2 does not build with kernels 2.6.20 or later. Use the
>>>>>> version bundled with that kernel. All patch fixes for OCFS2
>>>>>> applicable
>>>>>> to this kernel version and later are maintained here
>>>>>> <http://www.kernel.org/pub/linux/kernel/people/mfasheh/ocfs2/backports/>.
>>>>>>
>>>>>>
>>>>>>
>>>>>> </quote>
>>>>>>
>>>>>> Does this mean that after systems upgrade to kernel 2.6.20 we will
>>>>>> /only/ be able to use the kernel supplied ocfs2 version and must
>>>>>> upgrade
>>>>>> the kernel to use a newer release?
>>>>>>
>>>>>> Thanks,
>>>>>> Randy Ramsdell
>>>>>>
>>>>>> _______________________________________________
>>>>>> Ocfs2-users mailing list
>>>>>> Ocfs2-users at oss.oracle.com
>>>>>> http://oss.oracle.com/mailman/listinfo/ocfs2-users
>>>>>>
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> Ocfs2-users mailing list
>> Ocfs2-users at oss.oracle.com
>> http://oss.oracle.com/mailman/listinfo/ocfs2-users
>>
>