<?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 vs. SAS vs. SSD</title>
	<atom:link href="http://www.alexhopmann.com/2009/10/28/sata-vs-sas-vs-ssd/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.alexhopmann.com/2009/10/28/sata-vs-sas-vs-ssd/</link>
	<description>Modern Art makes me want to rock out</description>
	<pubDate>Fri, 10 Feb 2012 08:29:54 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: ambboy</title>
		<link>http://www.alexhopmann.com/2009/10/28/sata-vs-sas-vs-ssd/comment-page-1/#comment-193079</link>
		<dc:creator>ambboy</dc:creator>
		<pubDate>Mon, 06 Jun 2011 14:37:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.alexhopmann.com/?p=564#comment-193079</guid>
		<description>Right logic, wrong numbers for SATA.  Most SATA numbers I see (theoretical and real-world) put the IOPS for SATA at around 40.  Why?  The command queue has only a single-path and is only 32 while SAS has a command queue of 64 and two paths per disk.
After adjusting for the more realistic IOPS number, the SATA iops/$ should be 0.40 iops/$.
This number more accurately reflects the penalty.  However, when you factor in the longer rebuild times that require you to use RAID6, the penalty for using SATA in anything but low write IOPS environments becomes more apparent.  With SAS becoming common (less expensive), SATA will slowly go away.</description>
		<content:encoded><![CDATA[<p>Right logic, wrong numbers for SATA.  Most SATA numbers I see (theoretical and real-world) put the IOPS for SATA at around 40.  Why?  The command queue has only a single-path and is only 32 while SAS has a command queue of 64 and two paths per disk.<br />
After adjusting for the more realistic IOPS number, the SATA iops/$ should be 0.40 iops/$.<br />
This number more accurately reflects the penalty.  However, when you factor in the longer rebuild times that require you to use RAID6, the penalty for using SATA in anything but low write IOPS environments becomes more apparent.  With SAS becoming common (less expensive), SATA will slowly go away.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alex</title>
		<link>http://www.alexhopmann.com/2009/10/28/sata-vs-sas-vs-ssd/comment-page-1/#comment-134402</link>
		<dc:creator>Alex</dc:creator>
		<pubDate>Tue, 06 Apr 2010 22:21:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.alexhopmann.com/?p=564#comment-134402</guid>
		<description>KCockrell- good point, but two things. First of all, despite the manufacturer specs, I've read several sources where they didn't find real world (data center) reliability to be actually meaningfully different. Second, in any larger system you are going to have tons of failures of devices either way. With the SATA drives its easy to over-provision a bunch more (without adding too much cost)so even with a ton of failures everything keeps running smoothly.</description>
		<content:encoded><![CDATA[<p>KCockrell- good point, but two things. First of all, despite the manufacturer specs, I&#8217;ve read several sources where they didn&#8217;t find real world (data center) reliability to be actually meaningfully different. Second, in any larger system you are going to have tons of failures of devices either way. With the SATA drives its easy to over-provision a bunch more (without adding too much cost)so even with a ton of failures everything keeps running smoothly.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: KCockrell</title>
		<link>http://www.alexhopmann.com/2009/10/28/sata-vs-sas-vs-ssd/comment-page-1/#comment-133248</link>
		<dc:creator>KCockrell</dc:creator>
		<pubDate>Thu, 25 Mar 2010 20:03:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.alexhopmann.com/?p=564#comment-133248</guid>
		<description>"...interesting to observe that the SAS drives appear to never make sense..."

Reliability of commodity SATA is their biggest issue, and the most compelling SAS argument.</description>
		<content:encoded><![CDATA[<p>&#8220;&#8230;interesting to observe that the SAS drives appear to never make sense&#8230;&#8221;</p>
<p>Reliability of commodity SATA is their biggest issue, and the most compelling SAS argument.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alex</title>
		<link>http://www.alexhopmann.com/2009/10/28/sata-vs-sas-vs-ssd/comment-page-1/#comment-121860</link>
		<dc:creator>Alex</dc:creator>
		<pubDate>Fri, 30 Oct 2009 20:12:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.alexhopmann.com/?p=564#comment-121860</guid>
		<description>Often true- this stuff gets complicated when you need to apply real world usage patterns to the analysis. But future trends are also interesting to think about. Commodity SATA will likely continue to gain against SSD in GB/$, but I'd expect SSDs to get even faster (and 6Gb SATA will help them more too) while SATA drives will likely have constant performance characteristics.</description>
		<content:encoded><![CDATA[<p>Often true- this stuff gets complicated when you need to apply real world usage patterns to the analysis. But future trends are also interesting to think about. Commodity SATA will likely continue to gain against SSD in GB/$, but I&#8217;d expect SSDs to get even faster (and 6Gb SATA will help them more too) while SATA drives will likely have constant performance characteristics.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave Naffziger</title>
		<link>http://www.alexhopmann.com/2009/10/28/sata-vs-sas-vs-ssd/comment-page-1/#comment-121856</link>
		<dc:creator>Dave Naffziger</dc:creator>
		<pubDate>Fri, 30 Oct 2009 19:23:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.alexhopmann.com/?p=564#comment-121856</guid>
		<description>Great summary - one of the better ones I've seen yet.  While GB/$ should go up, I'd also expect IOPS/$ to rise as well.  We're finding IOPS to be the limiting factor in most of the cloud stuff we're doing.</description>
		<content:encoded><![CDATA[<p>Great summary - one of the better ones I&#8217;ve seen yet.  While GB/$ should go up, I&#8217;d also expect IOPS/$ to rise as well.  We&#8217;re finding IOPS to be the limiting factor in most of the cloud stuff we&#8217;re doing.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

