X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C8209B.7E6C42FA@onstor-exch02.onstor.net>; Tue, 6 Nov 2007 09:35:59 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C8209B.7E6C42FA"
Content-class: urn:content-classes:message
Subject: RE: Sun vs. NetApp (ZFS vs. NFS)
Date: Tue, 6 Nov 2007 09:35:58 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E066D19BA@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E066D1977@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Sun vs. NetApp (ZFS vs. NFS)
Thread-Index: AcggmHxOty2/dKKMRM662zXHrDXHOAAAq7ZA
References: <BB375AF679D4A34E9CA8DFA650E2B04E066D1977@onstor-exch02.onstor.net>
From: "Jobi Ariyamannil" <jobi.ariyamannil@onstor.com>
To: "Amit Bothra" <amit.bothra@onstor.com>,
	"dl-Engineering" <dl-engineering@onstor.com>,
	"dl-se" <dl-se@onstor.com>,
	"dl-Sales" <dl-sales@onstor.com>,
	"dl-Marketing" <dl-marketing@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8209B.7E6C42FA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I found the following comments about ZFS very interesting:

Comments
Hmmm. ZFS, while indeed very interesting, seems to be accompanied by a
significant amount of hype. Let's cut through some of it:
ZFS is not particularly fast (nor particularly slow). It does offer
above-average small-to-medium-sized update speed (a characteristic of
copy-on-write/batch-write-back implementations), but at the cost of
streaming-read performance for material thus written (because the small
updates are distributed around the storage rather than organized in
physical sequence as is the case in extent-based, update-in-place
systems with policies that minimize fragmentation). And it has a
'RAID-Z' implementation that can suffer dramatically by comparison to
conventional RAID-5 for workloads characterized by lots of parallel
small-to-medium-sized accesses (where RAID-Z performs more like RAID-3).
On the other hand, while more conventional file systems may be somewhat
faster for many workloads, ZFS does leverage its copy-on-write approach
to provide two atypical features:
1. Its updates are intrinsically 'atomic' - even if the system crashes
at an arbitrary moment, they either complete, or seem never to have
occurred at all. Conventional file systems don't normally guarantee this
by default (some files just don't need it, and others require some form
of recovery procedure after a crash anyway which can handle any
inconsistencies), and those that offer it as an option must write
updated material twice: first to a journal that will protect the update,
then to the final location - though the journal can be in NVRAM to make
the additional overhead negligible, or NVRAM write-back cache in the
storage hardware may effectively substitute for the journal, and when
material is being written for the first time rather than updated only
the structural pointers to it rather than the data itself need be thus
protected to guarantee atomicity.
2. ZFS can detect errors that conventional file systems cannot, by
virtue of special checksums that it embeds in its metadata. While the
frequency of these errors is too low to be important to the average
desktop user, in environments with unusually high reliability
requirements it provides an edge.
It's worth noting that the 'WAFL' file system in NetApp's line of
products provides similar features to those two described above, leading
to some discussion about just how much of ZFS actually *is* "Sun's
invention".
ZFS's extremely flexible use of a variety of storage devices may be more
unprecedented, and for environments that find conventional RAID
management challenging (especially when storage must grow) this may be
ZFS's most important feature (though it is a feature that some
virtualized arrays can come close to equaling when paired with more
conventional file systems). Unfortunately, it doesn't help when storage
needs grow to exceed the capacity of a single server, but at least makes
growth fairly painless up to that point. And the ability to use space
flexibly across multiple file systems within a common space pool
(similar to the ability to use underlying space flexibly across multiple
LUNs in a virtualized array) is also a manageability benefit.
So while ZFS really isn't all that 'close to perfect', nor as entirely
novel as Sun might have one believe, on the whole it does constitute a
measurable stride forward in storage and while not an ideal fit for
everyone should be an excellent fit for some.
Posted by: Bill Todd at November 3, 2007 02:32 AM=20


_____________________________________________
From: Amit Bothra=20
Sent: Tuesday, November 06, 2007 9:14 AM
To: dl-Engineering; dl-se; dl-Sales; dl-Marketing
Subject: Sun vs. NetApp (ZFS vs. NFS)

NetApp sues Sun for patent infringement (for ZFS)
http://www.computerworld.com/action/article.do?command=3DviewArticleBasic=
&
articleId=3D9034496

Sun' response =20
http://blogs.sun.com/jonathan/entry/harvesting_from_a_troll

Thanks,
Amit


------_=_NextPart_001_01C8209B.7E6C42FA
Content-Type: text/html;
	charset="us-ascii"
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>RE: Sun vs. NetApp (ZFS vs. NFS)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">I found the following comments =
about ZFS</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> =
<FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">very</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial"> interesting</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" =
SIZE=3D2 FACE=3D"Arial">:</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"></SPAN><A =
NAME=3D""><SPAN LANG=3D"en-us"></SPAN></A><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" =
SIZE=3D1 FACE=3D"Arial">Comments</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"></SPAN><A =
NAME=3D""><SPAN LANG=3D"en-us"></SPAN></A><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" =
SIZE=3D1 FACE=3D"Arial">Hmmm. ZFS, while indeed very interesting, seems =
to be accompanied by a significant amount of hype. Let's cut through =
some of it:</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">ZFS is not particularly fast (nor particularly slow). It =
does offer above-average small-to-medium-sized update speed (a =
characteristic of copy-on-write/batch-write-back implementations), but =
at the cost of streaming-read performance for material thus written =
(because the small updates are distributed around the storage rather =
than organized in physical sequence as is the case in extent-based, =
update-in-place systems with policies that minimize fragmentation). And =
it has a 'RAID-Z' implementation that can suffer dramatically by =
comparison to conventional RAID-5 for workloads characterized by lots of =
parallel small-to-medium-sized accesses (where RAID-Z performs more like =
RAID-3).</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">On the other hand, while more conventional file systems =
may be somewhat faster for many workloads, ZFS does leverage its =
copy-on-write approach to provide two atypical =
features:</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">1. Its updates are intrinsically 'atomic' - even if the =
system crashes at an arbitrary moment, they either complete, or seem =
never to have occurred at all. Conventional file systems don't normally =
guarantee this by default (some files just don't need it, and others =
require some form of recovery procedure after a crash anyway which can =
handle any inconsistencies), and those that offer it as an option must =
write updated material twice: first to a journal that will protect the =
update, then to the final location - though the journal can be in NVRAM =
to make the additional overhead negligible, or NVRAM write-back cache in =
the storage hardware may effectively substitute for the journal, and =
when material is being written for the first time rather than updated =
only the structural pointers to it rather than the data itself need be =
thus protected to guarantee atomicity.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">2. ZFS can detect errors that conventional file systems =
cannot, by virtue of special checksums that it embeds in its metadata. =
While the frequency of these errors is too low to be important to the =
average desktop user, in environments with unusually high reliability =
requirements it provides an edge.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">It's worth noting that the 'WAFL' file system in NetApp's =
line of products provides similar features to those two described above, =
leading to some discussion about just how much of ZFS actually *is* =
&quot;Sun's invention&quot;.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">ZFS's extremely flexible use of a variety of storage =
devices may be more unprecedented, and for environments that find =
conventional RAID management challenging (especially when storage must =
grow) this may be ZFS's most important feature (though it is a feature =
that some virtualized arrays can come close to equaling when paired with =
more conventional file systems). Unfortunately, it doesn't help when =
storage needs grow to exceed the capacity of a single server, but at =
least makes growth fairly painless up to that point. And the ability to =
use space flexibly across multiple file systems within a common space =
pool (similar to the ability to use underlying space flexibly across =
multiple LUNs in a virtualized array) is also a manageability =
benefit.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Arial">So while ZFS really isn't all that 'close to perfect', =
nor as entirely novel as Sun might have one believe, on the whole it =
does constitute a measurable stride forward in storage and while not an =
ideal fit for everyone should be an excellent fit for =
some.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT =
COLOR=3D"#000000" SIZE=3D1 FACE=3D"Arial">Posted by: Bill Todd at =
November 3, 2007 02:32 AM </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT =
SIZE=3D2 =
FACE=3D"Tahoma">_____________________________________________<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">From:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Amit Bothra<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Sent:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Tuesday, November 06, =
2007 9:14 AM<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">To:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> dl-Engineering; dl-se; =
dl-Sales; dl-Marketing<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Subject:</FONT></B></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Sun vs. NetApp (ZFS vs. NFS)</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT =
SIZE=3D2 FACE=3D"Arial">NetApp sues Sun for patent infringement (for =
ZFS)</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><A =
HREF=3D"http://www.computerworld.com/action/article.do?command=3DviewArti=
cleBasic&amp;articleId=3D9034496"><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.computerworld.com/action/article.do?command=3Dv=
iewArticleBasic&amp;articleId=3D9034496</FONT></U></SPAN><SPAN =
LANG=3D"en-us"></SPAN></A><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">Sun&#8217; response&nbsp; </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><A =
HREF=3D"http://blogs.sun.com/jonathan/entry/harvesting_from_a_troll"><SPA=
N LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 =
FACE=3D"Arial">http://blogs.sun.com/jonathan/entry/harvesting_from_a_trol=
l</FONT></U></SPAN><SPAN LANG=3D"en-us"></SPAN></A><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">Thanks,</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">Amit</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C8209B.7E6C42FA--
