<?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: StorageMojo&#8217;s best paper of FAST &#8217;10</title>
	<atom:link href="http://storagemojo.com/2010/03/05/storagemojos-best-paper-of-fast-10/feed/" rel="self" type="application/rss+xml" />
	<link>http://storagemojo.com/2010/03/05/storagemojos-best-paper-of-fast-10/</link>
	<description>Data storage info &#38; analysis</description>
	<lastBuildDate>Sun, 20 May 2012 13:26:14 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Jacob Marley</title>
		<link>http://storagemojo.com/2010/03/05/storagemojos-best-paper-of-fast-10/comment-page-1/#comment-208582</link>
		<dc:creator>Jacob Marley</dc:creator>
		<pubDate>Fri, 12 Mar 2010 00:35:33 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/?p=1926#comment-208582</guid>
		<description>From what I recall of the history/evolution of RAID levels, the original points were...
+ protection: Against entire disk failures.
+ performance: balance random vs sequential and read vs write
+etc

As storage density continues to grow, the probability of failing to consistently/reliably/accurately read a block is becoming significant.

Depending on the type of error encountered...
+ the entire drive may be bad or dying.
+ the block may be bad
+ the  block is good but the read was bad (probably correct if read it again).

Given the limitations of volume level RAID (slow rebuild times, etc) is it not time for file system or stripe level redundancy?</description>
		<content:encoded><![CDATA[<p>From what I recall of the history/evolution of RAID levels, the original points were&#8230;<br />
+ protection: Against entire disk failures.<br />
+ performance: balance random vs sequential and read vs write<br />
+etc</p>
<p>As storage density continues to grow, the probability of failing to consistently/reliably/accurately read a block is becoming significant.</p>
<p>Depending on the type of error encountered&#8230;<br />
+ the entire drive may be bad or dying.<br />
+ the block may be bad<br />
+ the  block is good but the read was bad (probably correct if read it again).</p>
<p>Given the limitations of volume level RAID (slow rebuild times, etc) is it not time for file system or stripe level redundancy?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Just A Storage Guy</title>
		<link>http://storagemojo.com/2010/03/05/storagemojos-best-paper-of-fast-10/comment-page-1/#comment-208529</link>
		<dc:creator>Just A Storage Guy</dc:creator>
		<pubDate>Tue, 09 Mar 2010 03:23:05 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/?p=1926#comment-208529</guid>
		<description>Joe,
I&#039;m not talking about whitebox solutions, I&#039;m talking about enterprise solutions from companies that actually turn a profit.

You&#039;re talking about multinode striping- the main reason why isilon&#039;s random io profile is terrible. I&#039;m talking about N+N protection- maybe I should have used lefthand as a better example.</description>
		<content:encoded><![CDATA[<p>Joe,<br />
I&#8217;m not talking about whitebox solutions, I&#8217;m talking about enterprise solutions from companies that actually turn a profit.</p>
<p>You&#8217;re talking about multinode striping- the main reason why isilon&#8217;s random io profile is terrible. I&#8217;m talking about N+N protection- maybe I should have used lefthand as a better example.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Kraska</title>
		<link>http://storagemojo.com/2010/03/05/storagemojos-best-paper-of-fast-10/comment-page-1/#comment-208520</link>
		<dc:creator>Joe Kraska</dc:creator>
		<pubDate>Mon, 08 Mar 2010 15:26:02 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/?p=1926#comment-208520</guid>
		<description>Just A Storage Guy,

Isilon does not have an &quot;abysmal&quot; raw-to-protected ratio. The reason being that the &quot;RAID set&quot; size is arbitrarily large. I put &quot;RAID set&quot; in quotes as it is not &quot;disks&quot; that Isilon protects, but rather data. So for example, in a cluster do dozens of controllers with hudnreds of drives, the effective protection of RAID plus 3 parity only costs you 3 drives worth of overhead, plus spares. This is a lot better than the classic RAID set limited vendors.

Your idea of using 15K drives instead of SATA, when compared to Isilon&#039;s approach, would be quite a lot more expensive, unless perhaps you are comparing a 15K bank of drives implemented by white box technology to the approach. However, Enterprise Storage is Enteprise Storage, and white box is white box. Let&#039;s not compare the two.

Joe Kraska
San Diego CA
USA</description>
		<content:encoded><![CDATA[<p>Just A Storage Guy,</p>
<p>Isilon does not have an &#8220;abysmal&#8221; raw-to-protected ratio. The reason being that the &#8220;RAID set&#8221; size is arbitrarily large. I put &#8220;RAID set&#8221; in quotes as it is not &#8220;disks&#8221; that Isilon protects, but rather data. So for example, in a cluster do dozens of controllers with hudnreds of drives, the effective protection of RAID plus 3 parity only costs you 3 drives worth of overhead, plus spares. This is a lot better than the classic RAID set limited vendors.</p>
<p>Your idea of using 15K drives instead of SATA, when compared to Isilon&#8217;s approach, would be quite a lot more expensive, unless perhaps you are comparing a 15K bank of drives implemented by white box technology to the approach. However, Enterprise Storage is Enteprise Storage, and white box is white box. Let&#8217;s not compare the two.</p>
<p>Joe Kraska<br />
San Diego CA<br />
USA</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aaron Brown</title>
		<link>http://storagemojo.com/2010/03/05/storagemojos-best-paper-of-fast-10/comment-page-1/#comment-208503</link>
		<dc:creator>Aaron Brown</dc:creator>
		<pubDate>Sun, 07 Mar 2010 19:02:02 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/?p=1926#comment-208503</guid>
		<description>s/spot a type/spot a typo/

(I assume.)</description>
		<content:encoded><![CDATA[<p>s/spot a type/spot a typo/</p>
<p>(I assume.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Just A Storage Guy</title>
		<link>http://storagemojo.com/2010/03/05/storagemojos-best-paper-of-fast-10/comment-page-1/#comment-208471</link>
		<dc:creator>Just A Storage Guy</dc:creator>
		<pubDate>Sat, 06 Mar 2010 01:55:03 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/?p=1926#comment-208471</guid>
		<description>I don&#039;t get the object based-systems idea as an iteration past raid- you&#039;re taking the raid5/6 overhead of 13% and replacing it with a 100%-400% overhead system. So disk densities doubled, but so did your protection scheme- so now you&#039;re back to square one. Why not just stick with the smaller drives and RAID5/6? Especially with power/cooling moving to the forefront, I don&#039;t see how technologies like isilon, lefthand, XIV, etc that have such abysmal raw-to-protected ratios make any sense? 1TB drives that I can only use 50% or less of them. Why not use 450gb 15k drives and spin about the same number of drives, but get 2x the iops?</description>
		<content:encoded><![CDATA[<p>I don&#8217;t get the object based-systems idea as an iteration past raid- you&#8217;re taking the raid5/6 overhead of 13% and replacing it with a 100%-400% overhead system. So disk densities doubled, but so did your protection scheme- so now you&#8217;re back to square one. Why not just stick with the smaller drives and RAID5/6? Especially with power/cooling moving to the forefront, I don&#8217;t see how technologies like isilon, lefthand, XIV, etc that have such abysmal raw-to-protected ratios make any sense? 1TB drives that I can only use 50% or less of them. Why not use 450gb 15k drives and spin about the same number of drives, but get 2x the iops?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

