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" <[EMAIL PROTECTED]>
To: "ocfs2-users" <[email protected]>
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
[email protected]
http://oss.oracle.com/mailman/listinfo/ocfs2-users
_______________________________________________
Ocfs2-users mailing list
[email protected]
http://oss.oracle.com/mailman/listinfo/ocfs2-users
_______________________________________________
Ocfs2-users mailing list
[email protected]
http://oss.oracle.com/mailman/listinfo/ocfs2-users
