[Ocfs2-users] ocfs2 custom builds

Randy Ramsdell rramsdell at livedatagroup.com
Thu Jul 19 05:57:30 PDT 2007


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




More information about the Ocfs2-users mailing list