<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Ask A Question, Get a Million Answers</title>
	<atom:link href="http://www.drunkendata.com/?feed=rss2&#038;p=1837" rel="self" type="application/rss+xml" />
	<link>http://www.drunkendata.com/?p=1837</link>
	<description>A blog for storage administrators and data managers.</description>
	<lastBuildDate>Fri, 23 Jul 2010 14:27:46 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>By: Jered</title>
		<link>http://www.drunkendata.com/?p=1837&#038;cpage=1#comment-18326</link>
		<dc:creator>Jered</dc:creator>
		<pubDate>Thu, 17 Jul 2008 17:48:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.drunkendata.com/?p=1837#comment-18326</guid>
		<description>&lt;i&gt;Block level deduplication is at issue here. Every vendor has its own algorithm which it regards as secret sauce. There are no standards.&lt;/i&gt;

There are standards.. standard interfaces on the front end, like NFS, CIFS and soon XAM.  Claiming this is scary because the guts of the dedupe differs from vendor to vendor is a red herring; the guts of any storage system differs from vendor to vendor.  

Look at hard drives -- I could claim by the same token that there are no standards there!  I can&#039;t take the platters out of a Hitachi drive and put them in a Seagate drive.  Each vendor has ECC codes and track formatting and magnetic domain shaping that they regard as secret sauce.  That doesn&#039;t make the disks any less reliable.

What matters here is the abstraction boundary provided by the user/application-facing interface, and if that maintains the integrity of the data, then it&#039;s a reliable data storage solution.  The bits you send to a hard drive never get written in that exact form on a disk -- they get translated into an entirely different bit pattern by an ECC code.  The bits that get written to tape with compression turned on aren&#039;t the original source bits.  And the bits on the drives in a deduplicating system are not the exact complement of bits sent to it.  But, in all three cases, when you use the application interface you always, always, always get back exactly what you wrote in the first place.

And that&#039;s what matters.</description>
		<content:encoded><![CDATA[<p><i>Block level deduplication is at issue here. Every vendor has its own algorithm which it regards as secret sauce. There are no standards.</i></p>
<p>There are standards.. standard interfaces on the front end, like NFS, CIFS and soon XAM.  Claiming this is scary because the guts of the dedupe differs from vendor to vendor is a red herring; the guts of any storage system differs from vendor to vendor.  </p>
<p>Look at hard drives &#8212; I could claim by the same token that there are no standards there!  I can&#8217;t take the platters out of a Hitachi drive and put them in a Seagate drive.  Each vendor has ECC codes and track formatting and magnetic domain shaping that they regard as secret sauce.  That doesn&#8217;t make the disks any less reliable.</p>
<p>What matters here is the abstraction boundary provided by the user/application-facing interface, and if that maintains the integrity of the data, then it&#8217;s a reliable data storage solution.  The bits you send to a hard drive never get written in that exact form on a disk &#8212; they get translated into an entirely different bit pattern by an ECC code.  The bits that get written to tape with compression turned on aren&#8217;t the original source bits.  And the bits on the drives in a deduplicating system are not the exact complement of bits sent to it.  But, in all three cases, when you use the application interface you always, always, always get back exactly what you wrote in the first place.</p>
<p>And that&#8217;s what matters.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
