<?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: FusionIO 320GB MLC benchmarks</title>
	<atom:link href="http://www.mysqlperformanceblog.com/2010/01/11/fusionio-320gb-mlc-benchmarks/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mysqlperformanceblog.com/2010/01/11/fusionio-320gb-mlc-benchmarks/</link>
	<description>Percona&#039;s MySQL &#38; InnoDB performance and scalability blog</description>
	<lastBuildDate>Sat, 11 Feb 2012 16:45:54 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Trent Hornibrook</title>
		<link>http://www.mysqlperformanceblog.com/2010/01/11/fusionio-320gb-mlc-benchmarks/comment-page-1/#comment-715581</link>
		<dc:creator>Trent Hornibrook</dc:creator>
		<pubDate>Fri, 29 Jan 2010 01:00:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=2009#comment-715581</guid>
		<description>Hi Vadim,

Awesome post - I see that DELL has updated their page and are now selling the Duo drive:

http://search.dell.com/results.aspx?s=gen&amp;c=us&amp;l=en&amp;cs=&amp;k=ioDrive&amp;cat=all&amp;x=0&amp;y=0

(Odd that the 640Gb is less than the 320!)

Curious to see your results when you benchmark with MySQL. 

I&#039;ve got my company looking at FusionIO now - just the cost ratio with consolidation against very expensive power and rackspace makes them attractive. Seems that for the price of 2-3 DELL 2950 with decent RAM we can get 2 FusionIO 320GB cards with the same spec&#039;ed DELLs... 

-Trent</description>
		<content:encoded><![CDATA[<p>Hi Vadim,</p>
<p>Awesome post &#8211; I see that DELL has updated their page and are now selling the Duo drive:</p>
<p><a href="http://search.dell.com/results.aspx?s=gen&#038;c=us&#038;l=en&#038;cs=&#038;k=ioDrive&#038;cat=all&#038;x=0&#038;y=0" rel="nofollow">http://search.dell.com/results.aspx?s=gen&#038;c=us&#038;l=en&#038;cs=&#038;k=ioDrive&#038;cat=all&#038;x=0&#038;y=0</a></p>
<p>(Odd that the 640Gb is less than the 320!)</p>
<p>Curious to see your results when you benchmark with MySQL. </p>
<p>I&#8217;ve got my company looking at FusionIO now &#8211; just the cost ratio with consolidation against very expensive power and rackspace makes them attractive. Seems that for the price of 2-3 DELL 2950 with decent RAM we can get 2 FusionIO 320GB cards with the same spec&#8217;ed DELLs&#8230; </p>
<p>-Trent</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Justin Swanhart</title>
		<link>http://www.mysqlperformanceblog.com/2010/01/11/fusionio-320gb-mlc-benchmarks/comment-page-1/#comment-709677</link>
		<dc:creator>Justin Swanhart</dc:creator>
		<pubDate>Thu, 14 Jan 2010 20:20:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=2009#comment-709677</guid>
		<description>A database doesn&#039;t have to be BCNF to do random I/O.   InnoDB secondary indexes on a denormalized table can generate a lot of random I/O too.  And while an SSD can improve join performance remember that all queries on MySQL are essentially single threaded (excluding for a moment the extra IO threads in XtraDB) so even with an optimal I/O subsystem there are plenty of other bottlenecks in joins such that denormalization will still almost always buy more performance.  Also don&#039;t forget that the optimizer may be forced to pick non-optimal join orders because of outer joins or hints, so just about any database which uses any joins can probably benefit at least somewhat from SSD.</description>
		<content:encoded><![CDATA[<p>A database doesn&#8217;t have to be BCNF to do random I/O.   InnoDB secondary indexes on a denormalized table can generate a lot of random I/O too.  And while an SSD can improve join performance remember that all queries on MySQL are essentially single threaded (excluding for a moment the extra IO threads in XtraDB) so even with an optimal I/O subsystem there are plenty of other bottlenecks in joins such that denormalization will still almost always buy more performance.  Also don&#8217;t forget that the optimizer may be forced to pick non-optimal join orders because of outer joins or hints, so just about any database which uses any joins can probably benefit at least somewhat from SSD.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert Young</title>
		<link>http://www.mysqlperformanceblog.com/2010/01/11/fusionio-320gb-mlc-benchmarks/comment-page-1/#comment-709666</link>
		<dc:creator>Robert Young</dc:creator>
		<pubDate>Thu, 14 Jan 2010 19:49:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=2009#comment-709666</guid>
		<description>These two sites have gobs of information about SSDs:

-- SSD news and history (some test reporting)
http://www.storagesearch.com/

-- extensive tests (this link is to latest)
http://www.anandtech.com/storage/showdoc.aspx?i=3667&amp;p=1


Points about SSD;
- NAND is commodity; Samsung parts are good, others maybe less.
- industrial strength drives (STEC, Texas, Fusion-io, and the like) have controllers which wear level the NAND such that one can write gigabytes/day and still last a decade or longer.  Intel&#039;s controller is still the most efficient in consumer devices.  SandForce and Indilinx are catching up.
- retail drives, Intel X-25M included, aren&#039;t up to server needs.  Pillar replaced Intel with STEC for this reason.
- PCIe devices, such as the Fusion-io, aren&#039;t really drives and aren&#039;t bootable without a device driver.  I recall reading that Fusion-io has a fix for Win7, but while they list a driver for RH/Suse and a build script for Debian/Ubuntu, I don&#039;t see that this driver supports booting; it may.

- Main Point:  don&#039;t bother using SSD if all you&#039;re doing is running flat-file images in some database (MySql developers do this a lot).  the real win with SSD is being able to run heavy join BCNF schemas, which are much smaller in footprint, and faster since they don&#039;t contain anywhere near the volume of bytes.</description>
		<content:encoded><![CDATA[<p>These two sites have gobs of information about SSDs:</p>
<p>&#8211; SSD news and history (some test reporting)<br />
<a href="http://www.storagesearch.com/" rel="nofollow">http://www.storagesearch.com/</a></p>
<p>&#8211; extensive tests (this link is to latest)<br />
<a href="http://www.anandtech.com/storage/showdoc.aspx?i=3667&#038;p=1" rel="nofollow">http://www.anandtech.com/storage/showdoc.aspx?i=3667&#038;p=1</a></p>
<p>Points about SSD;<br />
- NAND is commodity; Samsung parts are good, others maybe less.<br />
- industrial strength drives (STEC, Texas, Fusion-io, and the like) have controllers which wear level the NAND such that one can write gigabytes/day and still last a decade or longer.  Intel&#8217;s controller is still the most efficient in consumer devices.  SandForce and Indilinx are catching up.<br />
- retail drives, Intel X-25M included, aren&#8217;t up to server needs.  Pillar replaced Intel with STEC for this reason.<br />
- PCIe devices, such as the Fusion-io, aren&#8217;t really drives and aren&#8217;t bootable without a device driver.  I recall reading that Fusion-io has a fix for Win7, but while they list a driver for RH/Suse and a build script for Debian/Ubuntu, I don&#8217;t see that this driver supports booting; it may.</p>
<p>- Main Point:  don&#8217;t bother using SSD if all you&#8217;re doing is running flat-file images in some database (MySql developers do this a lot).  the real win with SSD is being able to run heavy join BCNF schemas, which are much smaller in footprint, and faster since they don&#8217;t contain anywhere near the volume of bytes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vadim</title>
		<link>http://www.mysqlperformanceblog.com/2010/01/11/fusionio-320gb-mlc-benchmarks/comment-page-1/#comment-709183</link>
		<dc:creator>Vadim</dc:creator>
		<pubDate>Wed, 13 Jan 2010 16:48:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=2009#comment-709183</guid>
		<description>Justin,

I&#039;d love that idea on website with benchmark results, but each time I think about it even
for publish my own results it seems very hard to implement properly..

There are so many scenarios and results, so I can&#039;t think how to formalize it.

But if you have insights how to do it - I would like to see!</description>
		<content:encoded><![CDATA[<p>Justin,</p>
<p>I&#8217;d love that idea on website with benchmark results, but each time I think about it even<br />
for publish my own results it seems very hard to implement properly..</p>
<p>There are so many scenarios and results, so I can&#8217;t think how to formalize it.</p>
<p>But if you have insights how to do it &#8211; I would like to see!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Justin Swanhart</title>
		<link>http://www.mysqlperformanceblog.com/2010/01/11/fusionio-320gb-mlc-benchmarks/comment-page-1/#comment-708975</link>
		<dc:creator>Justin Swanhart</dc:creator>
		<pubDate>Wed, 13 Jan 2010 07:21:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=2009#comment-708975</guid>
		<description>I&#039;m going to look at picking up a few Intels when I have the budget for more expensive playthings.  Testing out hardware products without the company sending them to you for evaluation is an expensive hobby.

I&#039;m thinking about creating a website dedicated to recording benchmark results.  Users could register results for existing benchmarks, such as DBT3, SSB or sysbench, or to register their own benchmark.  Vadim could register his &#039;ontime&#039; benchmark on the site then record the results he achieved on his hardware, along with those hardware specs.  Other users could run the same benchmark, and report their specs as well.  This way, people could test different engines and different hardware and compare other results easily.  

Does this sound like something useful?   Does something like this exist and I missed it?</description>
		<content:encoded><![CDATA[<p>I&#8217;m going to look at picking up a few Intels when I have the budget for more expensive playthings.  Testing out hardware products without the company sending them to you for evaluation is an expensive hobby.</p>
<p>I&#8217;m thinking about creating a website dedicated to recording benchmark results.  Users could register results for existing benchmarks, such as DBT3, SSB or sysbench, or to register their own benchmark.  Vadim could register his &#8216;ontime&#8217; benchmark on the site then record the results he achieved on his hardware, along with those hardware specs.  Other users could run the same benchmark, and report their specs as well.  This way, people could test different engines and different hardware and compare other results easily.  </p>
<p>Does this sound like something useful?   Does something like this exist and I missed it?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jos van Dongen</title>
		<link>http://www.mysqlperformanceblog.com/2010/01/11/fusionio-320gb-mlc-benchmarks/comment-page-1/#comment-708960</link>
		<dc:creator>Jos van Dongen</dc:creator>
		<pubDate>Wed, 13 Jan 2010 06:27:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=2009#comment-708960</guid>
		<description>@Justin
Tell me about it... I initially ordered 8 120 GB Vertex disks for my machine (that was the fastest solution *on paper*) but the Adaptec cards kept dropping the disks. Highly unstable combination. Luckily I could trade them in for 12 Intel 80 GB SSD&#039;s, and that works fine. Also have an X-25M in my Macbook now; amazing!</description>
		<content:encoded><![CDATA[<p>@Justin<br />
Tell me about it&#8230; I initially ordered 8 120 GB Vertex disks for my machine (that was the fastest solution *on paper*) but the Adaptec cards kept dropping the disks. Highly unstable combination. Luckily I could trade them in for 12 Intel 80 GB SSD&#8217;s, and that works fine. Also have an X-25M in my Macbook now; amazing!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patrick Casey</title>
		<link>http://www.mysqlperformanceblog.com/2010/01/11/fusionio-320gb-mlc-benchmarks/comment-page-1/#comment-708923</link>
		<dc:creator>Patrick Casey</dc:creator>
		<pubDate>Wed, 13 Jan 2010 02:57:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=2009#comment-708923</guid>
		<description>Matt, the &quot;normal&quot; failure mode that I&#039;m aware of on SSD&#039;s is the &quot;lockng&quot; of cells so that you can&#039;t rewrite them, basically they get stuck. Net result is you end up with a read-only drive, which is still a failure, but its a &quot;no data loss&quot; sort of failure. I guarantee there&#039;s other failure modes out there (Justin has an example), but, in theory at least, SSDs fail more safely than magnetic media.</description>
		<content:encoded><![CDATA[<p>Matt, the &#8220;normal&#8221; failure mode that I&#8217;m aware of on SSD&#8217;s is the &#8220;lockng&#8221; of cells so that you can&#8217;t rewrite them, basically they get stuck. Net result is you end up with a read-only drive, which is still a failure, but its a &#8220;no data loss&#8221; sort of failure. I guarantee there&#8217;s other failure modes out there (Justin has an example), but, in theory at least, SSDs fail more safely than magnetic media.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Justin Swanhart</title>
		<link>http://www.mysqlperformanceblog.com/2010/01/11/fusionio-320gb-mlc-benchmarks/comment-page-1/#comment-708882</link>
		<dc:creator>Justin Swanhart</dc:creator>
		<pubDate>Tue, 12 Jan 2010 23:51:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=2009#comment-708882</guid>
		<description>&gt;1. SSDâ€™s are a lot more reliable than traditional disks; even if they â€˜breakâ€™ youâ€™d still be able to read the data off them. But agreed, 
&gt; RAID 0 if great for benchmarking but not for a production database

Jos,

Tell that two the two 256GB OCZ Vertex SSD disks I have.   Both failed within two weeks of one another, in different systems.  Neither drive even shows up on the SATA bus when I connect the drives!

One disk was connected to a adaptec dual core SAS controller, and the other to a regular old internal Intel mobo SATA II connector.  

I&#039;ve honestly had serious performance or reliability issues with almost every SSD device I&#039;ve owned and tested.  I&#039;ve gone back to plain old arrays of inexpensive disks, at least for my home stuff.</description>
		<content:encoded><![CDATA[<p>&gt;1. SSDâ€™s are a lot more reliable than traditional disks; even if they â€˜breakâ€™ youâ€™d still be able to read the data off them. But agreed,<br />
&gt; RAID 0 if great for benchmarking but not for a production database</p>
<p>Jos,</p>
<p>Tell that two the two 256GB OCZ Vertex SSD disks I have.   Both failed within two weeks of one another, in different systems.  Neither drive even shows up on the SATA bus when I connect the drives!</p>
<p>One disk was connected to a adaptec dual core SAS controller, and the other to a regular old internal Intel mobo SATA II connector.  </p>
<p>I&#8217;ve honestly had serious performance or reliability issues with almost every SSD device I&#8217;ve owned and tested.  I&#8217;ve gone back to plain old arrays of inexpensive disks, at least for my home stuff.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: matt</title>
		<link>http://www.mysqlperformanceblog.com/2010/01/11/fusionio-320gb-mlc-benchmarks/comment-page-1/#comment-708878</link>
		<dc:creator>matt</dc:creator>
		<pubDate>Tue, 12 Jan 2010 23:40:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=2009#comment-708878</guid>
		<description>Ooops, not Intel, IBM ... lol</description>
		<content:encoded><![CDATA[<p>Ooops, not Intel, IBM &#8230; lol</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: matt</title>
		<link>http://www.mysqlperformanceblog.com/2010/01/11/fusionio-320gb-mlc-benchmarks/comment-page-1/#comment-708877</link>
		<dc:creator>matt</dc:creator>
		<pubDate>Tue, 12 Jan 2010 23:39:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/?p=2009#comment-708877</guid>
		<description>Solid State drives may be more reliable in the short term but, from my understanding based on a discussion with my brother-in-law who works for Micron (who supplies Intel), sold state has a tendency toward catastrophic failure.

When solid state devices are created a certain amount of extra memory is put into the device for fail-over.
As sections of memory die data is routed to the extra memory (that can not otherwise be accessed).
Unfortunately when the extra memory is used and any other memory is lost the solid state drive completely fails.

What I&#039;m suggesting (and not 100% sure of since there could be some technology I don&#039;t know about in SSD), is that the meantime before failure will generally be shorter in SSD drives than standard drives unless the SSDs are used primarily as READ devices (it&#039;s writes that make sections of memory fail).</description>
		<content:encoded><![CDATA[<p>Solid State drives may be more reliable in the short term but, from my understanding based on a discussion with my brother-in-law who works for Micron (who supplies Intel), sold state has a tendency toward catastrophic failure.</p>
<p>When solid state devices are created a certain amount of extra memory is put into the device for fail-over.<br />
As sections of memory die data is routed to the extra memory (that can not otherwise be accessed).<br />
Unfortunately when the extra memory is used and any other memory is lost the solid state drive completely fails.</p>
<p>What I&#8217;m suggesting (and not 100% sure of since there could be some technology I don&#8217;t know about in SSD), is that the meantime before failure will generally be shorter in SSD drives than standard drives unless the SSDs are used primarily as READ devices (it&#8217;s writes that make sections of memory fail).</p>
]]></content:encoded>
	</item>
</channel>
</rss>

