<?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: Flash performance update</title>
	<atom:link href="http://storagemojo.com/2008/02/02/flash-performance-update/feed/" rel="self" type="application/rss+xml" />
	<link>http://storagemojo.com/2008/02/02/flash-performance-update/</link>
	<description>Data storage info &#38; analysis</description>
	<lastBuildDate>Sun, 01 Aug 2010 02:16:15 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: A.T.</title>
		<link>http://storagemojo.com/2008/02/02/flash-performance-update/comment-page-1/#comment-174307</link>
		<dc:creator>A.T.</dc:creator>
		<pubDate>Fri, 22 Feb 2008 22:36:05 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/2008/02/02/flash-performance-update/#comment-174307</guid>
		<description>I wonder which &quot;science&quot; Mikko is into, probably some humanitarian - there is no single reference which filesystem he was testing (e.g. path to files stored could give basic idea), which version of SW is running... And yes, also you Rob could take into account one interesting detail - tablets are battery-driven devices, and one of main quality metrics is survivability through battery power loss... yes, try to avoid datacenter mentality - we do NOT burn electricity like there is no tomorrow, and have to keep device surviving in not-so-professional hands (read - prone to f#¤% up poor piece of electronics)</description>
		<content:encoded><![CDATA[<p>I wonder which &#8220;science&#8221; Mikko is into, probably some humanitarian &#8211; there is no single reference which filesystem he was testing (e.g. path to files stored could give basic idea), which version of SW is running&#8230; And yes, also you Rob could take into account one interesting detail &#8211; tablets are battery-driven devices, and one of main quality metrics is survivability through battery power loss&#8230; yes, try to avoid datacenter mentality &#8211; we do NOT burn electricity like there is no tomorrow, and have to keep device surviving in not-so-professional hands (read &#8211; prone to f#¤% up poor piece of electronics)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pete Steege</title>
		<link>http://storagemojo.com/2008/02/02/flash-performance-update/comment-page-1/#comment-168933</link>
		<dc:creator>Pete Steege</dc:creator>
		<pubDate>Mon, 04 Feb 2008 08:57:03 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/2008/02/02/flash-performance-update/#comment-168933</guid>
		<description>Amen, brother! Samsung and Seagate are pursuing a parallel path for these reasons.  I&#039;ve been posting on this quite a bit - here&#039;s my latest: http://storageeffect.com/2008/01/25/bill-watkins-the-journey-to-flash/</description>
		<content:encoded><![CDATA[<p>Amen, brother! Samsung and Seagate are pursuing a parallel path for these reasons.  I&#8217;ve been posting on this quite a bit &#8211; here&#8217;s my latest: <a href="http://storageeffect.com/2008/01/25/bill-watkins-the-journey-to-flash/" rel="nofollow">http://storageeffect.com/2008/01/25/bill-watkins-the-journey-to-flash/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Manolis</title>
		<link>http://storagemojo.com/2008/02/02/flash-performance-update/comment-page-1/#comment-168912</link>
		<dc:creator>Manolis</dc:creator>
		<pubDate>Mon, 04 Feb 2008 06:44:18 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/2008/02/02/flash-performance-update/#comment-168912</guid>
		<description>I came across an EETimes.com article on the &quot;Ashwood memory architecture&quot;:
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=205604434

It seems that Mr. Ashwood has a design that allows parallel data accesses to non-volatile memory.  A key challenge seems to be the &quot;translation layer&quot; - how do we take advantage of the potential for parallelism, especially for writes ?

Anyway, I thought this news item would be of interest to the readers of StorageMojo. 

Best regards,
Manolis.</description>
		<content:encoded><![CDATA[<p>I came across an EETimes.com article on the &#8220;Ashwood memory architecture&#8221;:<br />
<a href="http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=205604434" rel="nofollow">http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=205604434</a></p>
<p>It seems that Mr. Ashwood has a design that allows parallel data accesses to non-volatile memory.  A key challenge seems to be the &#8220;translation layer&#8221; &#8211; how do we take advantage of the potential for parallelism, especially for writes ?</p>
<p>Anyway, I thought this news item would be of interest to the readers of StorageMojo. </p>
<p>Best regards,<br />
Manolis.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ValB</title>
		<link>http://storagemojo.com/2008/02/02/flash-performance-update/comment-page-1/#comment-168904</link>
		<dc:creator>ValB</dc:creator>
		<pubDate>Mon, 04 Feb 2008 05:56:50 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/2008/02/02/flash-performance-update/#comment-168904</guid>
		<description>Hey Kevin (&amp; Robin),

One of the reasons NetApp is so excited about flash is the inherent advantage WAFL&#039;s write-anywhere architecture has for optimizing write performance to any device.  Look for us to articulate this more clearly throughout 2008.</description>
		<content:encoded><![CDATA[<p>Hey Kevin (&amp; Robin),</p>
<p>One of the reasons NetApp is so excited about flash is the inherent advantage WAFL&#8217;s write-anywhere architecture has for optimizing write performance to any device.  Look for us to articulate this more clearly throughout 2008.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin Burton</title>
		<link>http://storagemojo.com/2008/02/02/flash-performance-update/comment-page-1/#comment-168727</link>
		<dc:creator>Kevin Burton</dc:creator>
		<pubDate>Sun, 03 Feb 2008 12:09:18 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/2008/02/02/flash-performance-update/#comment-168727</guid>
		<description>On a related note, I&#039;ve been doing a BUNCH of performance testing of SSDs on my blog:

http://feedblog.org/2008/01/30/24-hours-with-an-ssd-and-mysql/
http://feedblog.org/2008/02/01/random-write-performance-in-ssds/
http://feedblog.org/2008/02/02/ssd-pbxt-crazy-suspicious/

Interesting so far but not as exciting as I would like.  The random write performance is far to slow for now.</description>
		<content:encoded><![CDATA[<p>On a related note, I&#8217;ve been doing a BUNCH of performance testing of SSDs on my blog:</p>
<p><a href="http://feedblog.org/2008/01/30/24-hours-with-an-ssd-and-mysql/" rel="nofollow">http://feedblog.org/2008/01/30/24-hours-with-an-ssd-and-mysql/</a><br />
<a href="http://feedblog.org/2008/02/01/random-write-performance-in-ssds/" rel="nofollow">http://feedblog.org/2008/02/01/random-write-performance-in-ssds/</a><br />
<a href="http://feedblog.org/2008/02/02/ssd-pbxt-crazy-suspicious/" rel="nofollow">http://feedblog.org/2008/02/02/ssd-pbxt-crazy-suspicious/</a></p>
<p>Interesting so far but not as exciting as I would like.  The random write performance is far to slow for now.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robin Harris</title>
		<link>http://storagemojo.com/2008/02/02/flash-performance-update/comment-page-1/#comment-168598</link>
		<dc:creator>Robin Harris</dc:creator>
		<pubDate>Sat, 02 Feb 2008 23:14:32 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/2008/02/02/flash-performance-update/#comment-168598</guid>
		<description>I don&#039;t think so. ONFI looks like a chip-level interface, not a fake-disk interface. It is the fake-disk or translation layer that appears to be the biggest problem in getting great flash SSD performance.

As you noted in your blog, the 3 largest NAND vendors aren&#039;t on board with ONFI and why should they be? They&#039;re selling all they can make without it. Why would Apple care? If and when Samsung goes with it, they will too. But as the world&#039;s largest consumer of flash Apple exists in its own ecosystem.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t think so. ONFI looks like a chip-level interface, not a fake-disk interface. It is the fake-disk or translation layer that appears to be the biggest problem in getting great flash SSD performance.</p>
<p>As you noted in your blog, the 3 largest NAND vendors aren&#8217;t on board with ONFI and why should they be? They&#8217;re selling all they can make without it. Why would Apple care? If and when Samsung goes with it, they will too. But as the world&#8217;s largest consumer of flash Apple exists in its own ecosystem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: infiniteadmin</title>
		<link>http://storagemojo.com/2008/02/02/flash-performance-update/comment-page-1/#comment-168591</link>
		<dc:creator>infiniteadmin</dc:creator>
		<pubDate>Sat, 02 Feb 2008 22:48:58 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/2008/02/02/flash-performance-update/#comment-168591</guid>
		<description>I thought the whole point of their ONFI initiative was to create this ecosystem.  Are the buyers of these chips all holding out from going the ONFI route? Apple hasn&#039;t given any sign of readiness to adopt the standard, right?  I wrote a few thoughts on this at my site.</description>
		<content:encoded><![CDATA[<p>I thought the whole point of their ONFI initiative was to create this ecosystem.  Are the buyers of these chips all holding out from going the ONFI route? Apple hasn&#8217;t given any sign of readiness to adopt the standard, right?  I wrote a few thoughts on this at my site.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
