<?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: The Worlds Fastest Storage</title>
	<atom:link href="http://blog.nigelpoulton.com/the-worlds-fastest-storage/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.nigelpoulton.com/the-worlds-fastest-storage/#utm_source=feed&amp;utm_medium=feed&amp;utm_campaign=feed</link>
	<description>with nigel poulton</description>
	<lastBuildDate>Tue, 20 Dec 2011 19:37:54 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Nigel (mackem)</title>
		<link>http://blog.nigelpoulton.com/the-worlds-fastest-storage/comment-page-1/#comment-79</link>
		<dc:creator>Nigel (mackem)</dc:creator>
		<pubDate>Mon, 20 Nov 2006 13:30:13 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=49#comment-79</guid>
		<description>Hi Liho, appreciate your feedback!  I wont be holding my breath for something like this from HDS then ;-)

While I appreciate Huâ€™s comments that a drawer full of memory can be expensive - so is cache memory and Flash Access licenses.  Just to clarify what I would like â€“ Im not after SSD that operates at the same speed as the expensive cache that goes in these top end subsystems.  Vendor documentation typically lists cache at around a thousand times faster than disk.  Id be happy with SSD that is just a couple of hundred times faster than disk â€“ sometimes Im just  too easily pleased ;-)

While I know that you can install large amounts of cache into HDS subsystems, we also tend to attach either lots of hosts or random I/O hungry apps to systems like these.  These can quickly push your cache write pending rate above the 40% mark causing the destaging process to speed up, and if the data keeps coming in at the same rate, it no longer matters how many paths to cache you have or how fast your cache is, your disks become a bottle-neck â€“ potentially hundreds of times slower than when cache was coping.

And once you start to pin LUNs into cache you obviously have less cache for your other workloads and that 40% mark becomes easier to hit.

I can also see how  installing drawers full of memory (to paraphrase Huâ€™s comment that you cited above) breaks the Hitachi physical architecture model in their enterprise subsystems ---&gt; If you install a drawer full of SSD, how then do you install a traditional 4 disk Array Group which is always spread across 4 HDU boxesâ€¦ suddenly one of those HDU boxes is for SSD and wont take your disks.  I know that Huâ€™s comment was in relation to lower end storage which doesnâ€™t have the same rules when installing Array Groups.

In the same article Hu mentions that 4 years is a lifetime in storage and lists a few examples to back up this claim - all of which relate to increasing capacity.  In 4 years time will the storage industry have gone through a lifetimes worth of change?  New bolt on products for ILM, security etc will no doubt come along but the basics of storage will not change - we will still hide slow disks behind limited cache.  When do we stop trying to hide slow disks behind larger and larger amounts of cache - will the next version of the USP stick to form and just double the addressable cache again?

Without  wanting to sound too much like a record player stuck on loop, I cant help but wonder if we are all a little conditioned by the industry to think that its OK that the disk drive is hundreds and hundreds of times slower than every other component in a computer.  And that SSD in the enterprise is too hard or still a long way off in the future â€“ lets be honest, people are already doing it and pretty successfully by the looks of it.

While I do think that HDS can be innovative and up there with the market leaders in some areas, I think they operate like big iron on some issues.  Ive previously read an article quoting Hu on EMC and their &quot;...20-plus year old Symmetric cache architecture.  I wouldnâ€™t be surprised to see similar comments coming out of places like Texas referring HDS, EMC, IBM with their XX year old disk based architectureâ€¦â€¦ still stuck in the past comparatively speaking.

Thanks again Liho - this is just my pennies worth.</description>
		<content:encoded><![CDATA[<p>Hi Liho, appreciate your feedback!  I wont be holding my breath for something like this from HDS then <img src='http://blog.nigelpoulton.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
<p>While I appreciate Huâ€™s comments that a drawer full of memory can be expensive &#8211; so is cache memory and Flash Access licenses.  Just to clarify what I would like â€“ Im not after SSD that operates at the same speed as the expensive cache that goes in these top end subsystems.  Vendor documentation typically lists cache at around a thousand times faster than disk.  Id be happy with SSD that is just a couple of hundred times faster than disk â€“ sometimes Im just  too easily pleased <img src='http://blog.nigelpoulton.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
<p>While I know that you can install large amounts of cache into HDS subsystems, we also tend to attach either lots of hosts or random I/O hungry apps to systems like these.  These can quickly push your cache write pending rate above the 40% mark causing the destaging process to speed up, and if the data keeps coming in at the same rate, it no longer matters how many paths to cache you have or how fast your cache is, your disks become a bottle-neck â€“ potentially hundreds of times slower than when cache was coping.</p>
<p>And once you start to pin LUNs into cache you obviously have less cache for your other workloads and that 40% mark becomes easier to hit.</p>
<p>I can also see how  installing drawers full of memory (to paraphrase Huâ€™s comment that you cited above) breaks the Hitachi physical architecture model in their enterprise subsystems &#8212;&gt; If you install a drawer full of SSD, how then do you install a traditional 4 disk Array Group which is always spread across 4 HDU boxesâ€¦ suddenly one of those HDU boxes is for SSD and wont take your disks.  I know that Huâ€™s comment was in relation to lower end storage which doesnâ€™t have the same rules when installing Array Groups.</p>
<p>In the same article Hu mentions that 4 years is a lifetime in storage and lists a few examples to back up this claim &#8211; all of which relate to increasing capacity.  In 4 years time will the storage industry have gone through a lifetimes worth of change?  New bolt on products for ILM, security etc will no doubt come along but the basics of storage will not change &#8211; we will still hide slow disks behind limited cache.  When do we stop trying to hide slow disks behind larger and larger amounts of cache &#8211; will the next version of the USP stick to form and just double the addressable cache again?</p>
<p>Without  wanting to sound too much like a record player stuck on loop, I cant help but wonder if we are all a little conditioned by the industry to think that its OK that the disk drive is hundreds and hundreds of times slower than every other component in a computer.  And that SSD in the enterprise is too hard or still a long way off in the future â€“ lets be honest, people are already doing it and pretty successfully by the looks of it.</p>
<p>While I do think that HDS can be innovative and up there with the market leaders in some areas, I think they operate like big iron on some issues.  Ive previously read an article quoting Hu on EMC and their &#8220;&#8230;20-plus year old Symmetric cache architecture.  I wouldnâ€™t be surprised to see similar comments coming out of places like Texas referring HDS, EMC, IBM with their XX year old disk based architectureâ€¦â€¦ still stuck in the past comparatively speaking.</p>
<p>Thanks again Liho &#8211; this is just my pennies worth.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Liho</title>
		<link>http://blog.nigelpoulton.com/the-worlds-fastest-storage/comment-page-1/#comment-78</link>
		<dc:creator>Liho</dc:creator>
		<pubDate>Sun, 19 Nov 2006 13:31:40 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=49#comment-78</guid>
		<description>Hu Yoshida&#039;s opinion: &quot;A drawer full of memory can be pretty expensive. We believe it is better to put it in cache where it can be shared across all drawers. As you noted we can lock a LUN in cache for peak use.&quot;

http://blogs.hds.com/hu/2006/03/four_years_is_a.html</description>
		<content:encoded><![CDATA[<p>Hu Yoshida&#8217;s opinion: &#8220;A drawer full of memory can be pretty expensive. We believe it is better to put it in cache where it can be shared across all drawers. As you noted we can lock a LUN in cache for peak use.&#8221;</p>
<p><a href="http://blogs.hds.com/hu/2006/03/four_years_is_a.html" rel="nofollow">http://blogs.hds.com/hu/2006/03/four_years_is_a.html</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>

