<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.4" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: The Capacity Illusion</title>
	<link>http://blogs.hds.com/hu/2006/10/the_capacity_il.html</link>
	<description>Hu Yoshida, VP and CTO of Hitachi Data Systems, provides his insight into industry issues, discusses in his own words storage best practices, and provides realistic solutions to real storage problems of current and next generation storage environments.</description>
	<pubDate>Fri, 29 Aug 2008 19:36:19 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>by: Darren Peacock</title>
		<link>http://blogs.hds.com/hu/2006/10/the_capacity_il.html#comment-1470</link>
		<pubDate>Tue, 12 Dec 2006 21:27:39 +0000</pubDate>
		<guid>http://blogs.hds.com/hu/2006/10/the_capacity_il.html#comment-1470</guid>
					<description>Think you miss another interesting point in the SPC benchmarks, HDS has consistantly been in the bottom 5% of performance and thru-put of results published for the past years. HDS OEM from Sun has resulted in published results, very very poor performace.
If you also see no benefit in publishing your SPC benchmarks that fine but hiding behind price performance continues a marketecture rather than architecture approach.</description>
		<content:encoded><![CDATA[<p>Think you miss another interesting point in the SPC benchmarks, HDS has consistantly been in the bottom 5% of performance and thru-put of results published for the past years. HDS OEM from Sun has resulted in published results, very very poor performace.<br />
If you also see no benefit in publishing your SPC benchmarks that fine but hiding behind price performance continues a marketecture rather than architecture approach.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Robin Harris</title>
		<link>http://blogs.hds.com/hu/2006/10/the_capacity_il.html#comment-265</link>
		<pubDate>Wed, 11 Oct 2006 16:41:30 +0000</pubDate>
		<guid>http://blogs.hds.com/hu/2006/10/the_capacity_il.html#comment-265</guid>
					<description>Hu, David Merrill dropped by StorageMojo.com as well, adding to the substantial number of comments on the post. Here is my most of my response to David:

When RAID arrays were developed, capacity was expensive and I/Os relatively cheap. Which is why the bright but impoverished academics and students at Cal came up with the idea of using small, cheap, unreliable drives to build a big reliable drive.

Now the world is different - or at least the technology is - and capacity is cheap and I/Os expensive and getting more so. Therefore, I submit, if Patterson et. al. were designing a fast, very big, very reliable drive today, it would look very different.

How? For one thing, lots of copies on different disks would provide both reliability and performance. Writes would be bunched for sequential write performance. Overwriting would be a background garbage collection function rather than a function of writing. Variable stripe writes might be implemented for performance. Cheap mirrored independent controllers might maintain small write caches if needed, rather than today’s costly dual-port caches.

I don’t know what a really clever team of engineers would design. I’m real confident that it would not be the 20 year old architecture we use today. That is why the discontinuities I saw in Hu’s posts are significant: customers are feeling uncomfortable, they don’t know why, and it is pointing to a bigger problem.

The company that designs and successfully markets the next generation (RAID 2.0?) storage array is going to make a hell of a lot of money. Why doesn’t HDS do it?


</description>
		<content:encoded><![CDATA[<p>Hu, David Merrill dropped by StorageMojo.com as well, adding to the substantial number of comments on the post. Here is my most of my response to David:</p>
<p>When RAID arrays were developed, capacity was expensive and I/Os relatively cheap. Which is why the bright but impoverished academics and students at Cal came up with the idea of using small, cheap, unreliable drives to build a big reliable drive.</p>
<p>Now the world is different - or at least the technology is - and capacity is cheap and I/Os expensive and getting more so. Therefore, I submit, if Patterson et. al. were designing a fast, very big, very reliable drive today, it would look very different.</p>
<p>How? For one thing, lots of copies on different disks would provide both reliability and performance. Writes would be bunched for sequential write performance. Overwriting would be a background garbage collection function rather than a function of writing. Variable stripe writes might be implemented for performance. Cheap mirrored independent controllers might maintain small write caches if needed, rather than today’s costly dual-port caches.</p>
<p>I don’t know what a really clever team of engineers would design. I’m real confident that it would not be the 20 year old architecture we use today. That is why the discontinuities I saw in Hu’s posts are significant: customers are feeling uncomfortable, they don’t know why, and it is pointing to a bigger problem.</p>
<p>The company that designs and successfully markets the next generation (RAID 2.0?) storage array is going to make a hell of a lot of money. Why doesn’t HDS do it?
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
