<?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: ZFS gets dedup</title>
	<atom:link href="http://pl.atyp.us/wordpress/?feed=rss2&#038;p=2450" rel="self" type="application/rss+xml" />
	<link>http://pl.atyp.us/wordpress/?p=2450</link>
	<description>Making the world better, one byte at a time.</description>
	<lastBuildDate>Sun, 05 Sep 2010 02:56:27 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Jeff Darcy</title>
		<link>http://pl.atyp.us/wordpress/?p=2450&#038;cpage=1#comment-142209</link>
		<dc:creator>Jeff Darcy</dc:creator>
		<pubDate>Tue, 03 Nov 2009 01:47:03 +0000</pubDate>
		<guid isPermaLink="false">http://pl.atyp.us/wordpress/?p=2450#comment-142209</guid>
		<description>I suspect that Jeff B&#039;s answer would be something about boiling the oceans, and with 256-bit hashes he might even have a point.  At some point the probability of a correlated hardware failure exceeds that of a hash collision, and the probability of a software bug dwarfs either.  Anybody who&#039;s *that* worried about a 1/2^128 chance shouldn&#039;t be using de-dup at all, even with &quot;verify&quot; set.

It is interesting, though, that Jeff B posts no actual performance &lt;b&gt;numbers&lt;/b&gt;, most notably those with &quot;verify&quot; turned on.  So far they seem to be sticking to their guns on the safety of running without verification, but even if they&#039;re proven wrong I&#039;d expect a round of benchmarks with it off because that makes them look better.</description>
		<content:encoded><![CDATA[<p>I suspect that Jeff B&#8217;s answer would be something about boiling the oceans, and with 256-bit hashes he might even have a point.  At some point the probability of a correlated hardware failure exceeds that of a hash collision, and the probability of a software bug dwarfs either.  Anybody who&#8217;s *that* worried about a 1/2^128 chance shouldn&#8217;t be using de-dup at all, even with &#8220;verify&#8221; set.</p>
<p>It is interesting, though, that Jeff B posts no actual performance <b>numbers</b>, most notably those with &#8220;verify&#8221; turned on.  So far they seem to be sticking to their guns on the safety of running without verification, but even if they&#8217;re proven wrong I&#8217;d expect a round of benchmarks with it off because that makes them look better.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Garzik</title>
		<link>http://pl.atyp.us/wordpress/?p=2450&#038;cpage=1#comment-142198</link>
		<dc:creator>Jeff Garzik</dc:creator>
		<pubDate>Mon, 02 Nov 2009 23:31:56 +0000</pubDate>
		<guid isPermaLink="false">http://pl.atyp.us/wordpress/?p=2450#comment-142198</guid>
		<description>Yuck, hash collisions rear their ugly head.

Being realistic, I think few people will run with the &#039;verify&#039; option enabled. Which is sad.

When considering truly -massive- amounts of storage, in use for years, the probability of a collision (like the probability of life on another planet) does increase.  And the cost of being wrong is -very- high: silent data corruption.</description>
		<content:encoded><![CDATA[<p>Yuck, hash collisions rear their ugly head.</p>
<p>Being realistic, I think few people will run with the &#8216;verify&#8217; option enabled. Which is sad.</p>
<p>When considering truly -massive- amounts of storage, in use for years, the probability of a collision (like the probability of life on another planet) does increase.  And the cost of being wrong is -very- high: silent data corruption.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
