<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/1.5.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Is RAID-6 made of wood?</title>
	<link>http://storageadvisors.adaptec.com/2005/11/03/is-raid-6-made-of-wood/</link>
	<description>Storage Solutions for Real World IT Professionals</description>
	<pubDate>Thu, 18 Mar 2010 11:43:23 +0000</pubDate>
	<generator>http://wordpress.org/?v=1.5.2</generator>

	<item>
 		<title>Comment on Is RAID-6 made of wood? by: Chad</title>
		<link>http://storageadvisors.adaptec.com/2005/11/03/is-raid-6-made-of-wood/#comment-6897</link>
		<pubDate>Tue, 25 Jul 2006 21:52:21 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2005/11/03/is-raid-6-made-of-wood/#comment-6897</guid>
					<description>Using commodity non-Enterprise drives for cost purposes with HS configured on each --  I need utter reliability...  

I was planning on a straight RAID 6 until I got enthused by ZFS...

Commodity desk top drives might fail slightly more than the enterprise ones but they cost less so I can get a few extras and in this configuration they should work fine.

Thanks for the interesting read!</description>
		<content:encoded><![CDATA[	<p>Using commodity non-Enterprise drives for cost purposes with HS configured on each &#8212;  I need utter reliability&#8230;  </p>
	<p>I was planning on a straight RAID 6 until I got enthused by ZFS&#8230;</p>
	<p>Commodity desk top drives might fail slightly more than the enterprise ones but they cost less so I can get a few extras and in this configuration they should work fine.</p>
	<p>Thanks for the interesting read!
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Is RAID-6 made of wood? by: Tom</title>
		<link>http://storageadvisors.adaptec.com/2005/11/03/is-raid-6-made-of-wood/#comment-6896</link>
		<pubDate>Tue, 25 Jul 2006 21:46:45 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2005/11/03/is-raid-6-made-of-wood/#comment-6896</guid>
					<description>Uh, yeah.  I think you're pretty safe.  ;-)</description>
		<content:encoded><![CDATA[	<p>Uh, yeah.  I think you&#8217;re pretty safe.  <img src='http://storageadvisors.adaptec.com/wp-images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' />
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Is RAID-6 made of wood? by: Chad</title>
		<link>http://storageadvisors.adaptec.com/2005/11/03/is-raid-6-made-of-wood/#comment-6895</link>
		<pubDate>Tue, 25 Jul 2006 21:39:06 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2005/11/03/is-raid-6-made-of-wood/#comment-6895</guid>
					<description>So I guess my 2 raid 6 arrays mirrored together with ZFS should be OK...</description>
		<content:encoded><![CDATA[	<p>So I guess my 2 raid 6 arrays mirrored together with ZFS should be OK&#8230;
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Is RAID-6 made of wood? by: Thomas</title>
		<link>http://storageadvisors.adaptec.com/2005/11/03/is-raid-6-made-of-wood/#comment-131</link>
		<pubDate>Fri, 17 Feb 2006 14:39:03 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2005/11/03/is-raid-6-made-of-wood/#comment-131</guid>
					<description>Tom,

If you look at this paper:

http://www.emulex.com/products/white/fcswitch/Advancing_Storage_Reliability_wp.pdf

you will see the typical claims for enhanced SBOD reliability through monitoring.

Here are the claims:

1)  JBODs use serially connected FC-AL topologies.  A rouge drive on an FC-AL segment may cause one or both FC-AL channels to become unavailable, potentially making all drives unavailable.  SBOD can isolate a rogue drive more effectively.

2) SBOD allows a newly inserted drive to be dynamically tested before it is ever placed into service.

3) SBOD controllers are better set up to monitor traffic trends to see potential bottlenecks going into individual drives, which may reveal drives that are about to go bad, but do not yet report CRC errors.

4) SBOD controllers examine words on FC links to each drive looking for CRC errors.  In JBOD, the source of CRC errors on the FC-AL can be elusive because of the shared, serial nature of the topology.  SBOD can track down the exact port and Source ALPA of frames with CRC errors.

5) SBOD can perform a clock check comparing the relative frequency of attached devices (both drives and initiators).  Identifying devices with out-of-tolerance clock frequencies allows them to be replaced under optimal system conditions before failure.

6) SBOD provides enhanced MTTRs because it can tell you right away which cabling error occured during repair.

The question is, does all that really matter, and if so, how much?</description>
		<content:encoded><![CDATA[	<p>Tom,</p>
	<p>If you look at this paper:</p>
	<p><a href='http://www.emulex.com/products/white/fcswitch/Advancing_Storage_Reliability_wp.pdf' rel='nofollow'>http://www.emulex.com/products/white/fcswitch/Advancing_Storage_Reliability_wp.pdf</a></p>
	<p>you will see the typical claims for enhanced SBOD reliability through monitoring.</p>
	<p>Here are the claims:</p>
	<p>1)  JBODs use serially connected FC-AL topologies.  A rouge drive on an FC-AL segment may cause one or both FC-AL channels to become unavailable, potentially making all drives unavailable.  SBOD can isolate a rogue drive more effectively.</p>
	<p>2) SBOD allows a newly inserted drive to be dynamically tested before it is ever placed into service.</p>
	<p>3) SBOD controllers are better set up to monitor traffic trends to see potential bottlenecks going into individual drives, which may reveal drives that are about to go bad, but do not yet report CRC errors.</p>
	<p>4) SBOD controllers examine words on FC links to each drive looking for CRC errors.  In JBOD, the source of CRC errors on the FC-AL can be elusive because of the shared, serial nature of the topology.  SBOD can track down the exact port and Source ALPA of frames with CRC errors.</p>
	<p>5) SBOD can perform a clock check comparing the relative frequency of attached devices (both drives and initiators).  Identifying devices with out-of-tolerance clock frequencies allows them to be replaced under optimal system conditions before failure.</p>
	<p>6) SBOD provides enhanced MTTRs because it can tell you right away which cabling error occured during repair.</p>
	<p>The question is, does all that really matter, and if so, how much?
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Is RAID-6 made of wood? by: Tom</title>
		<link>http://storageadvisors.adaptec.com/2005/11/03/is-raid-6-made-of-wood/#comment-129</link>
		<pubDate>Fri, 17 Feb 2006 13:13:09 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2005/11/03/is-raid-6-made-of-wood/#comment-129</guid>
					<description>Thomas,

Yep, I agree that a drive won't last 100 years.  MTBF is just a statistical measurement that becomes invalid after so many years.

Regarding predictive failure analysis, also known as PFA, or SMART:

A vendor saying that RAID-5 with SMART is better than RAID-6 is a little misleading.  Of course RAID-6 can also take advantage of SMART.

However I think I see the point they're trying to make.  Using SMART you can detect a bad drive before it fails and replace it, hopefully avoiding the condition of two simultaneous failures and thereby not requiring RAID-6.

But that's not why we should use RAID-6.  The main purpose of RAID-6 is to protect against bit errors detected during a rebuild.  SMART can't protect against that.

BTW, you mention an SBOD switch detecting SMART errors.  I've never seen a switch that does that.  RAID is done in an HBA or external controller.  Why would a switch be checking for SMART errors, and if it saw one, wouldn't it just inform the RAID stack anyway?  Or maybe I've misunderstood how they're defining an SBOD.  I usually think of a SBOD as being a JBOD with a switch - and therefore it's typically FC and soon SAS.

If you can tell me which vendor you're talking about, I'd love to look into what they have.

Thanks for reading.  I hope you find the posts useful.

TT</description>
		<content:encoded><![CDATA[	<p>Thomas,</p>
	<p>Yep, I agree that a drive won&#8217;t last 100 years.  MTBF is just a statistical measurement that becomes invalid after so many years.</p>
	<p>Regarding predictive failure analysis, also known as PFA, or SMART:</p>
	<p>A vendor saying that RAID-5 with SMART is better than RAID-6 is a little misleading.  Of course RAID-6 can also take advantage of SMART.</p>
	<p>However I think I see the point they&#8217;re trying to make.  Using SMART you can detect a bad drive before it fails and replace it, hopefully avoiding the condition of two simultaneous failures and thereby not requiring RAID-6.</p>
	<p>But that&#8217;s not why we should use RAID-6.  The main purpose of RAID-6 is to protect against bit errors detected during a rebuild.  SMART can&#8217;t protect against that.</p>
	<p>BTW, you mention an SBOD switch detecting SMART errors.  I&#8217;ve never seen a switch that does that.  RAID is done in an HBA or external controller.  Why would a switch be checking for SMART errors, and if it saw one, wouldn&#8217;t it just inform the RAID stack anyway?  Or maybe I&#8217;ve misunderstood how they&#8217;re defining an SBOD.  I usually think of a SBOD as being a JBOD with a switch - and therefore it&#8217;s typically FC and soon SAS.</p>
	<p>If you can tell me which vendor you&#8217;re talking about, I&#8217;d love to look into what they have.</p>
	<p>Thanks for reading.  I hope you find the posts useful.</p>
	<p>TT
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
