X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C864EF.92926F9B@onstor-exch02.onstor.net>; Fri, 1 Feb 2008 09:29:09 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C864EF.92926F9B"
Content-class: urn:content-classes:message
Subject: data corruption problem in submittal 5
Date: Fri, 1 Feb 2008 09:29:09 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E018AE843@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: data corruption problem in submittal 5
Thread-Index: Achk75KPUo/xNMLbSjyeVikik3qHnQ==
From: "Jeff Miller" <IMCEAEX-_O=ONSTOR_OU=FIRST+20ADMINISTRATIVE+20GROUP_CN=RECIPIENTS_CN=JEFF+2EMILLER@onstor.com>
To: "dl-Cougar" <dl-Cougar@onstor.com>

This is a multi-part message in MIME format.

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

Change 27512, which went in after submittal 5, solves a serious data =
corruption problem.  The corruption would occur during write to disk and =
a few bytes (probably 16) would be incorrect in the data received by the =
disk.  This problem showed up in Max's spec testing.

How much data integrity testing are we doing?  Can this problem be =
easily reproduced somehow using sub5, and the fix then verified with =
sub6?

Another thing to keep in mind is that an data written before submittal 6 =
may be
corrupted.

Jeff


------_=_NextPart_001_01C864EF.92926F9B
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.7653.38">
<TITLE>data corruption problem in submittal 5</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Change 27512, which went in after submittal 5, solves =
a serious data corruption problem.&nbsp; The corruption would occur =
during write to disk and a few bytes (probably 16) would be incorrect in =
the data received by the disk.&nbsp; This problem showed up in Max's =
spec testing.<BR>
<BR>
How much data integrity testing are we doing?&nbsp; Can this problem be =
easily reproduced somehow using sub5, and the fix then verified with =
sub6?<BR>
<BR>
Another thing to keep in mind is that an data written before submittal 6 =
may be<BR>
corrupted.<BR>
<BR>
Jeff<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C864EF.92926F9B--
