<?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: SATA Patter</title>
	<atom:link href="http://blog.nigelpoulton.com/sata-patter/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.nigelpoulton.com/sata-patter/#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: snig</title>
		<link>http://blog.nigelpoulton.com/sata-patter/comment-page-1/#comment-32</link>
		<dc:creator>snig</dc:creator>
		<pubDate>Thu, 26 Oct 2006 03:45:51 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=41#comment-32</guid>
		<description>I agree that keeping the RAID groups on a single controller helps performance a great bit.  e.g. RAID Group 0 on controller 0 and RAID Group 1 on controller 1.  In fact that&#039;s the way HDS will tell you to implement their controllers.</description>
		<content:encoded><![CDATA[<p>I agree that keeping the RAID groups on a single controller helps performance a great bit.  e.g. RAID Group 0 on controller 0 and RAID Group 1 on controller 1.  In fact that&#8217;s the way HDS will tell you to implement their controllers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jesse</title>
		<link>http://blog.nigelpoulton.com/sata-patter/comment-page-1/#comment-31</link>
		<dc:creator>Jesse</dc:creator>
		<pubDate>Thu, 26 Oct 2006 03:28:04 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=41#comment-31</guid>
		<description>Ok, I went to Powerlink (as an EMC freak) to try and look up the MTBF on the SATA vs. the SCSI and the FC drives, only to find powerlink down.

The biggest concern i can see is that SATA disks are single ported, where as fibrechannel disks are dual.  This means that only one storage processor (whatever brand) can have control of the disk at a time.  It also means that in failover scenarios data is forced to cross busses in one form or another to reach the port.  Whether that be through a hardware/software failover within the enclosure or through the SP, it can mean not as clean a failover.

As for performance, I&#039;ve found with the 18TB of SATA disks I&#039;ve got running on my Clariion (For Veritas Disk-Cache) as long as I keep the disks within a raid-group on the same storage processor, I&#039;m not noticing any bottlenecks.  (Before that, when I took the default of &quot;auto-assign&quot; I was noticing considerable queueing and &quot;wait for disk&quot; on the backup host during the peak backup window, with about 200 jobs running.)

I&#039;m running 6+1 Raid5 across the board and feel that if the back-end stripe is wide enough the pre-positioning will allow it to fly through writes.  Obviously I&#039;d have preferred to go Raid1+0 but couldn&#039;t get the budget for the 90+ drives that I would have needed to make that happen.</description>
		<content:encoded><![CDATA[<p>Ok, I went to Powerlink (as an EMC freak) to try and look up the MTBF on the SATA vs. the SCSI and the FC drives, only to find powerlink down.</p>
<p>The biggest concern i can see is that SATA disks are single ported, where as fibrechannel disks are dual.  This means that only one storage processor (whatever brand) can have control of the disk at a time.  It also means that in failover scenarios data is forced to cross busses in one form or another to reach the port.  Whether that be through a hardware/software failover within the enclosure or through the SP, it can mean not as clean a failover.</p>
<p>As for performance, I&#8217;ve found with the 18TB of SATA disks I&#8217;ve got running on my Clariion (For Veritas Disk-Cache) as long as I keep the disks within a raid-group on the same storage processor, I&#8217;m not noticing any bottlenecks.  (Before that, when I took the default of &#8220;auto-assign&#8221; I was noticing considerable queueing and &#8220;wait for disk&#8221; on the backup host during the peak backup window, with about 200 jobs running.)</p>
<p>I&#8217;m running 6+1 Raid5 across the board and feel that if the back-end stripe is wide enough the pre-positioning will allow it to fly through writes.  Obviously I&#8217;d have preferred to go Raid1+0 but couldn&#8217;t get the budget for the 90+ drives that I would have needed to make that happen.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mackem</title>
		<link>http://blog.nigelpoulton.com/sata-patter/comment-page-1/#comment-30</link>
		<dc:creator>mackem</dc:creator>
		<pubDate>Wed, 25 Oct 2006 21:10:26 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=41#comment-30</guid>
		<description>I think that patter is very much an English term rather than American - although I may be wrong on that.  May be its even from my local area in England... who knows ;-)

Re the possibility of firmware being an issue - a while ago I was working with some XP12K arrays and we had lots of failed FC drives which caused a lot of concern for such expensive disks (Seagate disks).  After a while it we were told that this was a firmware issue on not the physical disks.

Also before that I worked with some HP EVA boxes that went through a phase having loads FC drive failures.  We were told by our supplier that these were from a known bad batch.

So it goes to show that even the more expensive and thoroughly tested FC drives can also be unreliable.  Also if firmware can be the problem then no matter how well made your disk is, it can look like its failing just because somebody made a mistake when writing the firmware.</description>
		<content:encoded><![CDATA[<p>I think that patter is very much an English term rather than American &#8211; although I may be wrong on that.  May be its even from my local area in England&#8230; who knows <img src='http://blog.nigelpoulton.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
<p>Re the possibility of firmware being an issue &#8211; a while ago I was working with some XP12K arrays and we had lots of failed FC drives which caused a lot of concern for such expensive disks (Seagate disks).  After a while it we were told that this was a firmware issue on not the physical disks.</p>
<p>Also before that I worked with some HP EVA boxes that went through a phase having loads FC drive failures.  We were told by our supplier that these were from a known bad batch.</p>
<p>So it goes to show that even the more expensive and thoroughly tested FC drives can also be unreliable.  Also if firmware can be the problem then no matter how well made your disk is, it can look like its failing just because somebody made a mistake when writing the firmware.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: c2olen</title>
		<link>http://blog.nigelpoulton.com/sata-patter/comment-page-1/#comment-29</link>
		<dc:creator>c2olen</dc:creator>
		<pubDate>Wed, 25 Oct 2006 18:25:32 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=41#comment-29</guid>
		<description>Had to look up the word patter. Had no idea what it was supposed to mean in this context. Wikipedia helped me out.
Although we (the Dutch) can speak/read/write the English language quite well, some words just don&#039;t ring a bell. Patter doesn&#039;t seem to be used often, or am i mistaken on this?



On the SATA patter comments: I guess we had a bad batch then;-)
I exaggerated a bit, but from time to time, the failure rate is quite high, and 1 disk a week isn&#039;t uncommon. On many occasions a re-seat of the drive does the trick. So, it isn&#039;t always a real diskfailure. Nevertheless a rebuild of the array is at hand.
According to the vendor, this is a firmware issue. We&#039;ve done some upgrades in the last months, and the spindels seem to keep running longer now.</description>
		<content:encoded><![CDATA[<p>Had to look up the word patter. Had no idea what it was supposed to mean in this context. Wikipedia helped me out.<br />
Although we (the Dutch) can speak/read/write the English language quite well, some words just don&#8217;t ring a bell. Patter doesn&#8217;t seem to be used often, or am i mistaken on this?</p>
<p>On the SATA patter comments: I guess we had a bad batch then;-)<br />
I exaggerated a bit, but from time to time, the failure rate is quite high, and 1 disk a week isn&#8217;t uncommon. On many occasions a re-seat of the drive does the trick. So, it isn&#8217;t always a real diskfailure. Nevertheless a rebuild of the array is at hand.<br />
According to the vendor, this is a firmware issue. We&#8217;ve done some upgrades in the last months, and the spindels seem to keep running longer now.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Liho</title>
		<link>http://blog.nigelpoulton.com/sata-patter/comment-page-1/#comment-28</link>
		<dc:creator>Liho</dc:creator>
		<pubDate>Wed, 25 Oct 2006 16:39:53 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=41#comment-28</guid>
		<description>We&#039;re using 30 x 250GB SATA disks in 9570V. No any failure since installation (~ 18 months ago).</description>
		<content:encoded><![CDATA[<p>We&#8217;re using 30 x 250GB SATA disks in 9570V. No any failure since installation (~ 18 months ago).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: snig</title>
		<link>http://blog.nigelpoulton.com/sata-patter/comment-page-1/#comment-27</link>
		<dc:creator>snig</dc:creator>
		<pubDate>Wed, 25 Oct 2006 14:26:03 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=41#comment-27</guid>
		<description>We are using SATA in our shop and have not had a disk failure since we installed them back in March.  Roughly 13 TB of the stuff.

I have file servers, archive data, and even some development databases on the SATA drives.  They are running fine and was haven&#039;t seen any performance issues with them at all.

If at all possible I think users should give them a try before they discount them altogether.  I think they&#039;ll find them to be better than what some of the vendors would have them believe.</description>
		<content:encoded><![CDATA[<p>We are using SATA in our shop and have not had a disk failure since we installed them back in March.  Roughly 13 TB of the stuff.</p>
<p>I have file servers, archive data, and even some development databases on the SATA drives.  They are running fine and was haven&#8217;t seen any performance issues with them at all.</p>
<p>If at all possible I think users should give them a try before they discount them altogether.  I think they&#8217;ll find them to be better than what some of the vendors would have them believe.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: c2olen</title>
		<link>http://blog.nigelpoulton.com/sata-patter/comment-page-1/#comment-26</link>
		<dc:creator>c2olen</dc:creator>
		<pubDate>Wed, 25 Oct 2006 06:58:50 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.rupturedmonkey.com/?p=41#comment-26</guid>
		<description>Adding another plus to the SATA drives. When installed in a subsystem, they don&#039;t have to go through a firmware upgrade when upgrading a subsystems microcode. The disk i/o doesn&#039;t need to be suspended for these disks, as it is the case on some subsystems from the big-blue type vendors.

Although the failure rate of SATA disk drives in our shop ( 1 disk out of 200 fails each week ) proves me wrong, i could also imagine a couple of installations where SATA would suffice.
The current performance requirements of our shop exceeds SATA capabilities. But for small and medium sized companies, why not?

Damn, i could swear i had my blueprint for the NFDA here somewhere? How can i replace the RAID technology when i can&#039;t find my blueprints?</description>
		<content:encoded><![CDATA[<p>Adding another plus to the SATA drives. When installed in a subsystem, they don&#8217;t have to go through a firmware upgrade when upgrading a subsystems microcode. The disk i/o doesn&#8217;t need to be suspended for these disks, as it is the case on some subsystems from the big-blue type vendors.</p>
<p>Although the failure rate of SATA disk drives in our shop ( 1 disk out of 200 fails each week ) proves me wrong, i could also imagine a couple of installations where SATA would suffice.<br />
The current performance requirements of our shop exceeds SATA capabilities. But for small and medium sized companies, why not?</p>
<p>Damn, i could swear i had my blueprint for the NFDA here somewhere? How can i replace the RAID technology when i can&#8217;t find my blueprints?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

