<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/1.5.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: It&#8217;s the software, stupid</title>
	<link>http://storageadvisors.adaptec.com/2005/10/30/its-the-software-stupid/</link>
	<description>Storage Solutions for Real World IT Professionals</description>
	<pubDate>Wed, 17 Mar 2010 03:57:02 +0000</pubDate>
	<generator>http://wordpress.org/?v=1.5.2</generator>

	<item>
 		<title>Comment on It&#8217;s the software, stupid by: Tom</title>
		<link>http://storageadvisors.adaptec.com/2005/10/30/its-the-software-stupid/#comment-63</link>
		<pubDate>Wed, 16 Nov 2005 13:04:03 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2005/10/30/its-the-software-stupid/#comment-63</guid>
					<description>It's a retorhical question, but why the heck are hetrogenous FC systems so unstable.  FC is an ANSI spec defining how SCSI commands are put on a serial wire.  (That's somewhat of a simplification, but not by much.)  What's so hard about that?  The FC vendors definitely made enough money to afford a little compatibility testing.  The mess they've created is just sad.  Don't even get me started about FATA drives.  How silly.

I'm looking forward to seeing 10G iSCSI squeeze FC from the top and SAS/SATA squeeze FC from the bottom.  Excuse me if I giggle.

TT</description>
		<content:encoded><![CDATA[	<p>It&#8217;s a retorhical question, but why the heck are hetrogenous FC systems so unstable.  FC is an ANSI spec defining how SCSI commands are put on a serial wire.  (That&#8217;s somewhat of a simplification, but not by much.)  What&#8217;s so hard about that?  The FC vendors definitely made enough money to afford a little compatibility testing.  The mess they&#8217;ve created is just sad.  Don&#8217;t even get me started about FATA drives.  How silly.</p>
	<p>I&#8217;m looking forward to seeing 10G iSCSI squeeze FC from the top and SAS/SATA squeeze FC from the bottom.  Excuse me if I giggle.</p>
	<p>TT
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on It&#8217;s the software, stupid by: Jon Toigo</title>
		<link>http://storageadvisors.adaptec.com/2005/10/30/its-the-software-stupid/#comment-55</link>
		<pubDate>Mon, 14 Nov 2005 14:30:39 +0000</pubDate>
		<guid>http://storageadvisors.adaptec.com/2005/10/30/its-the-software-stupid/#comment-55</guid>
					<description>Tom,

Greed and hardware complexity go hand in hand, IMHO.  The original motivation for adding a lot of complex foo to arrays might have been goodness -- building a better mousetrap, that sort of thing -- but today array controller design and I/O pathing are used by enterprise storage vendors by and large to lock out their competitors and lock in their customers.

Look at EMC Centerra, ostensibly a platform for tracking archival data over the long haul, but in reality just a Japanese Mortgage.  The vendor has taken FilePool software from an acquired Belgian company and wedded it to a proprietary controller in order to 1) jack up the cost of otherwise commodity components on the array and 2) to lock the customer into a data encoding scheme from which extrication will be near impossible. In effect, grab the customer by his data, and his heart and mind and wallet will follow.

Not to pick on EMC only (though they are notorious in this regard), there are many other examples we could cite -- from HP, IBM and many others.

The need is to purpose-build storage based on what applications require.  That will inevitably require heterogeneous storage (not all from one vendor).  FC fabrics aren't the solution because they are unstable (if heterogeneous) and because they lack the intelligence required to give applications the drink of storage they require, rather than a common drink of storage for all.

Thanks for the cite.

Jon Toigo</description>
		<content:encoded><![CDATA[	<p>Tom,</p>
	<p>Greed and hardware complexity go hand in hand, IMHO.  The original motivation for adding a lot of complex foo to arrays might have been goodness &#8212; building a better mousetrap, that sort of thing &#8212; but today array controller design and I/O pathing are used by enterprise storage vendors by and large to lock out their competitors and lock in their customers.</p>
	<p>Look at EMC Centerra, ostensibly a platform for tracking archival data over the long haul, but in reality just a Japanese Mortgage.  The vendor has taken FilePool software from an acquired Belgian company and wedded it to a proprietary controller in order to 1) jack up the cost of otherwise commodity components on the array and 2) to lock the customer into a data encoding scheme from which extrication will be near impossible. In effect, grab the customer by his data, and his heart and mind and wallet will follow.</p>
	<p>Not to pick on EMC only (though they are notorious in this regard), there are many other examples we could cite &#8212; from HP, IBM and many others.</p>
	<p>The need is to purpose-build storage based on what applications require.  That will inevitably require heterogeneous storage (not all from one vendor).  FC fabrics aren&#8217;t the solution because they are unstable (if heterogeneous) and because they lack the intelligence required to give applications the drink of storage they require, rather than a common drink of storage for all.</p>
	<p>Thanks for the cite.</p>
	<p>Jon Toigo
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
