<?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: 20 year old architectures</title>
	<link>http://blogs.hds.com/hu/2006/10/20_year_old_arc.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:47:02 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>by: NT</title>
		<link>http://blogs.hds.com/hu/2006/10/20_year_old_arc.html#comment-43535</link>
		<pubDate>Fri, 16 Nov 2007 21:15:35 +0000</pubDate>
		<guid>http://blogs.hds.com/hu/2006/10/20_year_old_arc.html#comment-43535</guid>
					<description>"Im curious what your thoughts are on the benefits a back-end switching architecture might bring to speeding up RAID rebuild times - is the shared bus/loop architecture seen on the back end of many subsystems a factor in slowing down parity rebuilds?"

Back-end switching won't have any effect on rebuilt times as you will still be reconstructing to a single drive. That means that reconstruction can not be faster that the write throughput of a single disk.</description>
		<content:encoded><![CDATA[<p>&#8220;Im curious what your thoughts are on the benefits a back-end switching architecture might bring to speeding up RAID rebuild times - is the shared bus/loop architecture seen on the back end of many subsystems a factor in slowing down parity rebuilds?&#8221;</p>
<p>Back-end switching won&#8217;t have any effect on rebuilt times as you will still be reconstructing to a single drive. That means that reconstruction can not be faster that the write throughput of a single disk.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: mds32767</title>
		<link>http://blogs.hds.com/hu/2006/10/20_year_old_arc.html#comment-40903</link>
		<pubDate>Tue, 30 Oct 2007 11:31:29 +0000</pubDate>
		<guid>http://blogs.hds.com/hu/2006/10/20_year_old_arc.html#comment-40903</guid>
					<description>Hi Hu,

Our HDS team *casually* mentioned that 750GB ATA drive support for the USP-V will be announced Monday October 10th and will be available on November 14th. 1TB ATA soon to follow. I almost fell out of my chair! 

With this in mind, how would you qualify your above statement that "Intermixing, slower, less reliable SATA or FATA disks in tier 1 storage systems will impact that system’s performance and availability with more frequent drive failures and longer rebuild times which consumes internal bandwidth, cache, and controller cycles. For these reason’s we do not offer FATA disks in our USP/NSC, preferring to attach them through external disk systems."</description>
		<content:encoded><![CDATA[<p>Hi Hu,</p>
<p>Our HDS team *casually* mentioned that 750GB ATA drive support for the USP-V will be announced Monday October 10th and will be available on November 14th. 1TB ATA soon to follow. I almost fell out of my chair! </p>
<p>With this in mind, how would you qualify your above statement that &#8220;Intermixing, slower, less reliable SATA or FATA disks in tier 1 storage systems will impact that system’s performance and availability with more frequent drive failures and longer rebuild times which consumes internal bandwidth, cache, and controller cycles. For these reason’s we do not offer FATA disks in our USP/NSC, preferring to attach them through external disk systems.&#8221;
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: morris hoodye</title>
		<link>http://blogs.hds.com/hu/2006/10/20_year_old_arc.html#comment-37390</link>
		<pubDate>Sat, 29 Sep 2007 00:32:54 +0000</pubDate>
		<guid>http://blogs.hds.com/hu/2006/10/20_year_old_arc.html#comment-37390</guid>
					<description>It's time we start using storage media which doesn't depend on a spinning disc. 

The use of semiconductors for storage would result in reduction of power and heat.</description>
		<content:encoded><![CDATA[<p>It&#8217;s time we start using storage media which doesn&#8217;t depend on a spinning disc. </p>
<p>The use of semiconductors for storage would result in reduction of power and heat.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Mark</title>
		<link>http://blogs.hds.com/hu/2006/10/20_year_old_arc.html#comment-14387</link>
		<pubDate>Mon, 02 Apr 2007 21:52:51 +0000</pubDate>
		<guid>http://blogs.hds.com/hu/2006/10/20_year_old_arc.html#comment-14387</guid>
					<description>I don't understand the fail-spare-replace-copyback approach of storage system disk management.  With global spares, the copyback should not be required.  Why do we still do things this way?  Why does not the old spare become the new drive, and the old drive, once replaced, the new spare?  Perhaps it is because of a physical disk layout (i.e., "all spare disks will occupy slot 14").  Or it could be optimization of the paths for performance and availability.

So it seems the ideal would be to create a true back-end fabric (as opposed to loop) architecture so there is no performance or availability reason to copyback.  Then just specify a number or percentage of disks in the spare pool.  If a disk fails, replace that physical disk.  Anything else is needless complexity which should have been automated out of storage arrays a decade ago.

Next, regarding the capacity vs. I/O cost tradeoff, if capacity is cheap, but I/Os are expensive, a return to RAID 1 (or 1+0) semantics may be in order.  At least narrower stripes may be in order, especially for SATA.  Some customers are doubling their stripe width with RAID6 compared to RAID5, so as to keep their capacity costs constant.

Maybe it is time to consider a 4-disk wide RAID 6 stripe:  The same capacity as mirroring, but you still have a RAID 5 level of protection with a single disk failure.  However, many fewer I/Os are required to rebuild a disk.  Imagine a system which immediately block copied the entire affected LUN to a new LUN, rather than a spare-in of disk.  This would allow full-stripe writes to the new volume instead of Read Modify Writes to the spare.  Spare volumes rather than spare disks are certainly possible if capacity is cheap.

Or maybe the answer is in RAID 1 with an automated ability to access a DR or HSM copy if a second drive fails.  The performance of a long-wave accessed copy, or a SATA copy after a FC drive failure, may be similar to accessing a degraded RAID5 or RAID6 volume.  This would quite literally be "thinking outside of the box", with respect to the storage array.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t understand the fail-spare-replace-copyback approach of storage system disk management.  With global spares, the copyback should not be required.  Why do we still do things this way?  Why does not the old spare become the new drive, and the old drive, once replaced, the new spare?  Perhaps it is because of a physical disk layout (i.e., &#8220;all spare disks will occupy slot 14&#8243;).  Or it could be optimization of the paths for performance and availability.</p>
<p>So it seems the ideal would be to create a true back-end fabric (as opposed to loop) architecture so there is no performance or availability reason to copyback.  Then just specify a number or percentage of disks in the spare pool.  If a disk fails, replace that physical disk.  Anything else is needless complexity which should have been automated out of storage arrays a decade ago.</p>
<p>Next, regarding the capacity vs. I/O cost tradeoff, if capacity is cheap, but I/Os are expensive, a return to RAID 1 (or 1+0) semantics may be in order.  At least narrower stripes may be in order, especially for SATA.  Some customers are doubling their stripe width with RAID6 compared to RAID5, so as to keep their capacity costs constant.</p>
<p>Maybe it is time to consider a 4-disk wide RAID 6 stripe:  The same capacity as mirroring, but you still have a RAID 5 level of protection with a single disk failure.  However, many fewer I/Os are required to rebuild a disk.  Imagine a system which immediately block copied the entire affected LUN to a new LUN, rather than a spare-in of disk.  This would allow full-stripe writes to the new volume instead of Read Modify Writes to the spare.  Spare volumes rather than spare disks are certainly possible if capacity is cheap.</p>
<p>Or maybe the answer is in RAID 1 with an automated ability to access a DR or HSM copy if a second drive fails.  The performance of a long-wave accessed copy, or a SATA copy after a FC drive failure, may be similar to accessing a degraded RAID5 or RAID6 volume.  This would quite literally be &#8220;thinking outside of the box&#8221;, with respect to the storage array.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Mackem</title>
		<link>http://blogs.hds.com/hu/2006/10/20_year_old_arc.html#comment-288</link>
		<pubDate>Mon, 23 Oct 2006 21:43:15 +0000</pubDate>
		<guid>http://blogs.hds.com/hu/2006/10/20_year_old_arc.html#comment-288</guid>
					<description>Hi Hu,
Im curious what your thoughts are on the benefits a back-end switching architecture might bring to speeding up RAID rebuild times - is the shared bus/loop architecture seen on the back end of many subsystems a factor in slowing down parity rebuilds?</description>
		<content:encoded><![CDATA[<p>Hi Hu,<br />
Im curious what your thoughts are on the benefits a back-end switching architecture might bring to speeding up RAID rebuild times - is the shared bus/loop architecture seen on the back end of many subsystems a factor in slowing down parity rebuilds?
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Hubert Yoshida</title>
		<link>http://blogs.hds.com/hu/2006/10/20_year_old_arc.html#comment-267</link>
		<pubDate>Wed, 18 Oct 2006 23:01:02 +0000</pubDate>
		<guid>http://blogs.hds.com/hu/2006/10/20_year_old_arc.html#comment-267</guid>
					<description>Good question. Its hard to know what you have when it has been sitting idle for some time. With spinning disks we keep monitoring it to see if it's operating properly. Plus we have RAID for reconstruction.  
</description>
		<content:encoded><![CDATA[<p>Good question. Its hard to know what you have when it has been sitting idle for some time. With spinning disks we keep monitoring it to see if it&#8217;s operating properly. Plus we have RAID for reconstruction.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Neil melville</title>
		<link>http://blogs.hds.com/hu/2006/10/20_year_old_arc.html#comment-266</link>
		<pubDate>Wed, 18 Oct 2006 09:58:30 +0000</pubDate>
		<guid>http://blogs.hds.com/hu/2006/10/20_year_old_arc.html#comment-266</guid>
					<description>Hi HU,
      Enjoy your blogs,and yes Disks have changed for the better over the years I do not worry about head crashes,but saying that we became very good at backup and restores I just wonder now if we needed to that we could get all our data back from tape?</description>
		<content:encoded><![CDATA[<p>Hi HU,<br />
      Enjoy your blogs,and yes Disks have changed for the better over the years I do not worry about head crashes,but saying that we became very good at backup and restores I just wonder now if we needed to that we could get all our data back from tape?
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
