[Ocfs2-users] ocfs2 custom builds

[Alexei_Roudnev]

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.

All other combinations are extremely experimental by nature - they can work, 
but you must test everything including fencing, heavy load and so on.

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.

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.

----- 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
>