From: Alexei_Roudnev (Alexei_Roudnev_at_exigengroup.com)
Date: Fri Mar 09 2007 - 20:05:28 CET
Message-ID: <079401c7627d$e72c9080$6401a8c0@alexh> From: "Alexei_Roudnev" <Alexei_Roudnev@exigengroup.com> Date: Fri, 9 Mar 2007 11:05:28 -0800 Subject: [suse-sles-e] Re: [Ocfs2-users] ocfs2 is still eating memory
It's exactly what I am saying. I was 100%, no 200% sure that _OCFSv2 don't
work in SLES10 release__ - knowing how it was tested and how Novell gets
bug reports, and how system changed, it was obvious. Trying to explain it to
SuSe beta manager - got response like _everything alright, we have a lot of
official beta testers,
we don't need open beta, we don't need a noise about errors from people not
on high support, don't worry be happy.
At the same time, I saw people who was very serious about making SLES10 +
OCFSv2 + EVMS + heartbeat2 work (in novell). So they really did a lot to
make it all work.
But - the whole testing system, feedback system, QA system, rush to release
and include features make me absolutely sure , that _no, you even should not
try OCFS on SLES10 until at least SP1_.
Now, see reports - people are saying the same -- it don't work.
It do work in SLES9 SP3 #283, I don't know any issues there (they do exists
but I don't know, to be clean). I use it in some second-importance tasks,
some problem until build 282, now disappeared.
Fencing problems comes from OCFS itself and are design flow. But - can you
purchases SLEs9, for example when ordering new DELL server? Not. Can you
have SLES9 on new AMD servers? Not. How long ago did we had servicepack for
SLES9 ? 1 year and even more (we have about 20 kernel updates already, some
critical). Looks as SLES9 is almost abandoned (again, manager response from
SuSe - don't worry be happy - when I asked about it) .
Now compare with RHEL approach. RHEL4.4 is rock solid system. RHEL5 is in
beta for almost 1 year, we have a lot of rpm's for it, but it is STILL IN
BETA. Anyone can download and try. People have a good choice. Company have a
good testing bed. And when it will be released, it will be rock solid again
(and dont require to rep[lace yum repository system, for example, as you
must replace YOU replicattion system to the hack for ZenWorks in SLES). I
don't like RHEL Linux as a Linux, but I like RHEL roadmap as a roadmap.
Support is to make things work on customer's site. If something advertised
do not work, it must be fixed with or without support contract, feedback
must be taken with or without support contract, and people must be realistic
about the quality. If you can't do it - use better beta programm, attract
more pre-release users, attract community. It is truth about _high priests
in glass tower in Novell_.
(PS. I moved it from ocfs2 list to suse-sles list.)
----- Original Message -----
From: "John Lange" <john.lange@open-it.ca>
To: "Sunil Mushran" <Sunil.Mushran@oracle.com>
Cc: "ocfs2-users" <ocfs2-users@oss.oracle.com>; "Lars Marowsky-Bree"
<lmb@suse.de>; "Alexei_Roudnev" <Alexei_Roudnev@exigengroup.com>
Sent: Friday, March 09, 2007 7:44 AM
Subject: Re: [Ocfs2-users] ocfs2 is still eating memory
> Lets be clear, we have 4 licensed copies of SLES10.
>
> What we will not do is pay for premium support just to get the system to
> operate as advertised. And besides, what would premium support get us?
> Does it make the system magically start working? No. Does it mean Novell
> will fix the bug quickly and send us a patch? No. It actually just means
> that they _might_ let you report a bug and they _may_ think about fixing
> it but probably not. More likely they will just send you another
> response with some excuse about how they can't do anything (see below).
>
> I'm starting to see a lot of high priests sitting in towers at Novell.
>
> See if this quote rings true:
>
> "I believed that the most important software ... needed to be built like
> cathedrals, carefully crafted by individual wizards or small bands of
> mages working in splendid isolation, with no beta to be released before
> its time."
>
> It's starting to seem like someone at Novell needs to read the
> "Cathedral and the Bazaar".
>
> Let me be clear, I think the SUSE products are among the best! But there
> is no possible way they can stay that way unless Novell stops trying to
> impose a closed source mentality.
>
> Fundamentally, OpenSource requires that users not only have access to
> the software, but to be part of the development process which includes
> bug reporting and interaction with the developers.
>
> And in return we are happy to pay for licensed copies to support the
> OpenSource development process.
>
> Lars, I see your other reply explaining the way SUSE/Novell operates and
> I want to make sure you understand that I really do appreciate that you
> are personally taking the issue seriously.
>
> However, I want to tell you that if you are waiting for this to appear
> in the official support channel you are going to be disappointed. This
> is the reply from Novell support:
>
> "the version of SLES that you are running is unsupported through the
> official channels. When you installed SLES 10 SP1, you had to click
> through a license that stated that it is Beta software and that we
> cannot provide support."
>
> Just to be clear, we are _not_ running SP1. We are only using the Kernel
> of the day in an attempt to fix the memory problem.
>
> And in any case, we aren't even asking for support, we are just trying
> to report a bug through the proper channels.
>
> John
>
> On Thu, 2007-03-08 at 16:37 -0800, Sunil Mushran wrote:
> > If you are running a prod shop, you should looking into buying support.
> >
> > John Lange wrote:
> > > On Mon, 2007-03-05 at 13:46 -0800, Sunil Mushran wrote:
> > >
> > >> Well, kswapd is supposed to flush the caches. As in, the vm
> > >> controls the lifetime of the inodes in the inode_cache not ocfs2.
> > >>
> > >> All ocfs2 can do is free the memory associated with the inode when
> > >> asked to. And it does that when you manually flush the cache. Qs is
> > >> why the vm is not doing it on its own. (fwiw, you are on a beta
kernel.)
> > >>
> > >
> > > We are using beta kernels in an attempt to solve this problem. As
> > > everyone knows, the most recent official SUSE kernel (2.6.16.21-0.25 i
> > > believe?) completely broke ocfs2. Downgrading to 2.6.16.21-0.15 solves
> > > that problem but the memory issue remains.
> > >
> > > So as far as I am aware, there is no SUSE kernel that works with ocfs2
> > > which is where we find ourselves today.
> > >
> > > I just upgraded to the latest KOTD:
> > >
> > > 2.6.16.42-SLES10_SP1_BRANCH_20070307114604-smp
> > >
> > > And still, when running ocfs2, all ram gets consumed.
> > >
> > > Right now Novell is playing the "you don't have premium support" game
so
> > > where should I report this bug?
> > >
> > > Regards,
> > >
> > > John Lange
> > >
> > >
> > >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com
For additional commands, e-mail: suse-sles-e-help@suse.com
This archive was generated by hypermail 2.1.7 : Fri Mar 09 2007 - 22:09:41 CET