<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.4" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: SSD Flash or DRAM</title>
	<link>http://blogs.hds.com/hu/2008/01/ssd_flash_or_dram.html</link>
	<description>Hu Yoshida, the CTO of Hitachi Data Systems, provides his insight into industry issues, discusses in his own words storage best practices, and provides realistic solutions to real storage needs in today</description>
	<pubDate>Wed, 23 Jul 2008 21:24:31 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>by: Captain Conniff</title>
		<link>http://blogs.hds.com/hu/2008/01/ssd_flash_or_dram.html#comment-54417</link>
		<pubDate>Thu, 07 Feb 2008 05:00:28 +0000</pubDate>
		<guid>http://blogs.hds.com/hu/2008/01/ssd_flash_or_dram.html#comment-54417</guid>
					<description>Hu,
In your blog you say that EMC announced "Virtual Partitioning"? Do you mean "Virtual Provisioning"? As in thin provisioning done right, for instance the thin provisioned LUN can be replicated, cloned or integrated into other enterprise functionality that customers desire? 

Or do you mean dynamic cache partioning? As in the ability to dynamically partition cache for various workloads that can be tuned without having to IML the array?  I know that it can be confusing as EMC DMX has so much functionality it's hard to keep up with?

Thanks for your blog!</description>
		<content:encoded><![CDATA[<p>Hu,<br />
In your blog you say that EMC announced &#8220;Virtual Partitioning&#8221;? Do you mean &#8220;Virtual Provisioning&#8221;? As in thin provisioning done right, for instance the thin provisioned LUN can be replicated, cloned or integrated into other enterprise functionality that customers desire? </p>
<p>Or do you mean dynamic cache partioning? As in the ability to dynamically partition cache for various workloads that can be tuned without having to IML the array?  I know that it can be confusing as EMC DMX has so much functionality it&#8217;s hard to keep up with?</p>
<p>Thanks for your blog!
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Paul</title>
		<link>http://blogs.hds.com/hu/2008/01/ssd_flash_or_dram.html#comment-52988</link>
		<pubDate>Tue, 29 Jan 2008 00:57:19 +0000</pubDate>
		<guid>http://blogs.hds.com/hu/2008/01/ssd_flash_or_dram.html#comment-52988</guid>
					<description>Hu,

If HDS would be interested in an alternative to flash ssd, we are developing a non-volatile dram-based enterprise-class SSD designed for seamless integration with storage arrays.  It is fundamentally less expensive than a flash approach, has no write limitations and is 8x-10x faster than EMCs quoted performance for the STEC drives.

Best,

-Paul</description>
		<content:encoded><![CDATA[<p>Hu,</p>
<p>If HDS would be interested in an alternative to flash ssd, we are developing a non-volatile dram-based enterprise-class SSD designed for seamless integration with storage arrays.  It is fundamentally less expensive than a flash approach, has no write limitations and is 8x-10x faster than EMCs quoted performance for the STEC drives.</p>
<p>Best,</p>
<p>-Paul
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Andrey Kuzmin</title>
		<link>http://blogs.hds.com/hu/2008/01/ssd_flash_or_dram.html#comment-52150</link>
		<pubDate>Tue, 22 Jan 2008 22:03:36 +0000</pubDate>
		<guid>http://blogs.hds.com/hu/2008/01/ssd_flash_or_dram.html#comment-52150</guid>
					<description>&#62; What if you have a write failure in the middle of a database 
&#62; transaction, where some of the writes have already been committed? 
Sorry, but this has nothing to do with flash per se: any write within a transaction could fail whatever media database back-end resides on (even RAM), and DBMS MUST be prepared to handle this.

As to flash vs. DRAM, the former is superior to the latter in a single but extremely important respect: non-volatility. This, INO, will make flash most welcomed replacement for NVRAM in DBMS and file-system worlds to provide low-latency non-volatile log storage.

Regards,
Andrey
P.S. And thanks for the post, insightful as usually.</description>
		<content:encoded><![CDATA[<p>&gt; What if you have a write failure in the middle of a database<br />
&gt; transaction, where some of the writes have already been committed?<br />
Sorry, but this has nothing to do with flash per se: any write within a transaction could fail whatever media database back-end resides on (even RAM), and DBMS MUST be prepared to handle this.</p>
<p>As to flash vs. DRAM, the former is superior to the latter in a single but extremely important respect: non-volatility. This, INO, will make flash most welcomed replacement for NVRAM in DBMS and file-system worlds to provide low-latency non-volatile log storage.</p>
<p>Regards,<br />
Andrey<br />
P.S. And thanks for the post, insightful as usually.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Nick Allen</title>
		<link>http://blogs.hds.com/hu/2008/01/ssd_flash_or_dram.html#comment-52135</link>
		<pubDate>Tue, 22 Jan 2008 18:56:09 +0000</pubDate>
		<guid>http://blogs.hds.com/hu/2008/01/ssd_flash_or_dram.html#comment-52135</guid>
					<description>Hu:

Regarding SMART

According to STEC, and the 110 page ZeusIops operating manual, SMART is fully supported today and worn-out/bad pages are reported as bad "sectors" while spare pages are used to replace these bad pages. 

-Nick</description>
		<content:encoded><![CDATA[<p>Hu:</p>
<p>Regarding SMART</p>
<p>According to STEC, and the 110 page ZeusIops operating manual, SMART is fully supported today and worn-out/bad pages are reported as bad &#8220;sectors&#8221; while spare pages are used to replace these bad pages. </p>
<p>-Nick
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Dan Pancamo</title>
		<link>http://blogs.hds.com/hu/2008/01/ssd_flash_or_dram.html#comment-52052</link>
		<pubDate>Tue, 22 Jan 2008 04:26:55 +0000</pubDate>
		<guid>http://blogs.hds.com/hu/2008/01/ssd_flash_or_dram.html#comment-52052</guid>
					<description>It's not a question of IF, but WHEN the mechanical drive will come to an end.   While EMC's announcement may be mostly a marketing ploy for now, it's working.

We want SSD!</description>
		<content:encoded><![CDATA[<p>It&#8217;s not a question of IF, but WHEN the mechanical drive will come to an end.   While EMC&#8217;s announcement may be mostly a marketing ploy for now, it&#8217;s working.</p>
<p>We want SSD!
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
