X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C72283.CCC3ADDC@onstor-exch02.onstor.net>; Mon, 18 Dec 2006 01:06:27 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C72283.CCC3ADDC"
References: <BB375AF679D4A34E9CA8DFA650E2B04ECAA58D@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E0A90E4@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04EC62540@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E578AD5@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E013D27D5@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E0A90E5@onstor-exch02.onstor.net>
Content-class: urn:content-classes:message
Subject: RE: Cheetah soak running Clio RC2
Date: Mon, 18 Dec 2006 01:06:27 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E01336094@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Cheetah soak running Clio RC2
thread-index: AcchTR42d4oXwOZuQ2G+XQIuycaLqQADNtgnAANG0tAABgaX7AAAEGgQAAHo5YEAABc8QAAAo19KAB1kdPYAAICmdQAC9MS1AAfXHcgAA16AjAACFBY3AACIWG8ADALYwgACtjV9
From: "Ken Renshaw" <ken.renshaw@onstor.com>
To: "Larry Scheer" <larry.scheer@onstor.com>,
	"Paul Hammer" <paul.hammer@onstor.com>,
	"Jay Michlin" <jay.michlin@onstor.com>,
	"Caeli Collins" <caeli.collins@onstor.com>,
	"Narayan Venkat" <narayan.venkat@onstor.com>,
	"Tim Gardner" <tim.gardner@onstor.com>,
	"Sandrine Boulanger" <sandrine.boulanger@onstor.com>,
	"dl-Clio" <dl-Clio@onstor.com>,
	"Andy Sharp" <andy.sharp@onstor.com>
Cc: "Eric Barrett" <eric.barrett@onstor.com>,
	"Ed Kwan" <ed.kwan@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C72283.CCC3ADDC
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

*** I can only point out that since 1.3.3. we started shipping the =
WEB-UI which grew the distribution file to=20
    40+ Mbytes. I have heard some folk-lore about tar files over 40 =
Mbytes being trouble. I am
    still investigating this to see if it is an issue. It is one thing =
that is common to the releases though.

KLR> This is not folklore Larry, it is fact, and you yourself have been =
involved in shrinking the tarfile ( the magic number we should be =
looking at for this is not the absolute size of the tarball, but rather =
the expanded size of this tarball into the /tmp/ramdisk memfs space =
during system upgrade in which the size is greater than or close to the =
limit of the allocated ramdisk ). As I said, this is not folklore or =
conjecture, it is a fact based upon the size of the installation package =
we've seen before....we have unequivocably seen that tarballs that =
expand to over the allotment of the memfs filesystem descriptor type =
invariably result in crashes or corruptions, and this has been true =
since 1.2.x. That size was determined at the time to be ~40mb, and I =
still consider that a good starting point since the bad flash card =
theory does not make sense ( why would the same files be affected if it =
was a random flash failure?? ).

Andy, considering our version of OpenBSD is there a window by which that =
memfs ramdisk allocations can get stomped on? If your answer is no, is =
there *any* case that you know of by which memory swap issues can affect =
allocated ramdisks in finite ( small ) physical RAM environments??

Up until now we have stripping binaries and the like to mask this =
problem and shrink the tarball. It is my conjecture that this related to =
the issue since it's about the only thing that makes sense right now, =
and I'd very much like dev to prove or disprove it since it's been a =
long-standing problem. Since we know it is a problem in 1.3.2/1.3.3, and =
dates back to much earlier, I now think at least part of this problem is =
related to the multiple failures we've seen. I do not agree that Dev =
should not care in the context of ongoing development, nor that there is =
not a solution discernable that can explain it, and I totally stand =
behind Caeli and Paul that we need to understand it before we can even =
think of releasing 2.1.0.0. As Paul said, it doesn't matter how much =
good work was done in Clio if the customer has upgrade issues, it's =
meaningless since if the customer is down.

Quality is everyone's job, not just Quality Engineering, and I truly =
believe that Dev should not take such a contextual stance as to state =
otherwise. There is more to a release than just checking off boxes on a =
feature-chart, and likewise believe everyone involved should take a =
wider stance to ensure quality code hits the customers. In all it's =
aspects.

-Ken



------_=_NextPart_001_01C72283.CCC3ADDC
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7650.28">
<TITLE>RE: Cheetah soak running Clio RC2</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>*** I can only point out that since 1.3.3. we started =
shipping the WEB-UI which grew the distribution file to<BR>
&nbsp;&nbsp;&nbsp; 40+ Mbytes. I have heard some folk-lore about tar =
files over 40 Mbytes being trouble. I am<BR>
&nbsp;&nbsp;&nbsp; still investigating this to see if it is an issue. It =
is one thing that is common to the releases though.<BR>
<BR>
KLR&gt; This is not folklore Larry, it is fact, and you yourself have =
been involved in shrinking the tarfile ( the magic number we should be =
looking at for this is not the absolute size of the tarball, but rather =
the expanded size of this tarball into the /tmp/ramdisk memfs space =
during system upgrade in which the size is greater than or close to the =
limit of the allocated ramdisk ). As I said, this is not folklore or =
conjecture, it is a fact based upon the size of the installation package =
we've seen before....we have unequivocably seen that tarballs that =
expand to over the allotment of the memfs filesystem descriptor type =
invariably result in crashes or corruptions, and this has been true =
since 1.2.x. That size was determined at the time to be ~40mb, and I =
still consider that a good starting point since the bad flash card =
theory does not make sense ( why would the same files be affected if it =
was a random flash failure?? ).<BR>
<BR>
Andy, considering our version of OpenBSD is there a window by which that =
memfs ramdisk allocations can get stomped on? If your answer is no, is =
there *any* case that you know of by which memory swap issues can affect =
allocated ramdisks in finite ( small ) physical RAM environments??<BR>
<BR>
Up until now we have stripping binaries and the like to mask this =
problem and shrink the tarball. It is my conjecture that this related to =
the issue since it's about the only thing that makes sense right now, =
and I'd very much like dev to prove or disprove it since it's been a =
long-standing problem. Since we know it is a problem in 1.3.2/1.3.3, and =
dates back to much earlier, I now think at least part of this problem is =
related to the multiple failures we've seen. I do not agree that Dev =
should not care in the context of ongoing development, nor that there is =
not a solution discernable that can explain it, and I totally stand =
behind Caeli and Paul that we need to understand it before we can even =
think of releasing 2.1.0.0. As Paul said, it doesn't matter how much =
good work was done in Clio if the customer has upgrade issues, it's =
meaningless since if the customer is down.<BR>
<BR>
Quality is everyone's job, not just Quality Engineering, and I truly =
believe that Dev should not take such a contextual stance as to state =
otherwise. There is more to a release than just checking off boxes on a =
feature-chart, and likewise believe everyone involved should take a =
wider stance to ensure quality code hits the customers. In all it's =
aspects.<BR>
<BR>
-Ken<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C72283.CCC3ADDC--
