hard drives

More on Seagate vs. STEC

by dave on April 15, 2008

EDIT:  4/15/08 @ 827pm EST

After careful consideration, it has become apparent to me that putting myself in jeopardy of commenting on active litigation that (potentially) involves my employer isn’t a smart thing to do. That being said, I’ve decided to leave this content here, but with the following disclaimer:

The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC. The information I’ve presented below is through personal research through publically available news sources (news.google.com and other media outlets) and does not represent anything but a high level overview of the potential consequences of this lawsuit. 

As I was holding my 11 day old daughter last night (about 3am or so), I kept going back to this whole lawsuit issue between Seagate and STEC. There were a few things that were bugging me about the nature of this suit and, I thought I’d pose them here.

a.) Why STEC? In my mind, STEC represents the first successful ENTERPRISE foray for SSD drives in the storage market. BiTMICRO and mTron have done an excellent job of being the performance leaders for consumer drives, but, never quite reached that pinnacle of performance and reliability that is needed in the enterprise storage space. As such, STEC represents the single greatest danger to Seagate and their ability to continue to push FC disk as the performance leader in enterprise (SAS is another great challenger to that concept, but we’ll leave that for another discussion). Additionally, as pricing parity is reached between SSDs and magnetic disk, there becomes an even greater divide between price and performance.

The other aspect of “why STEC” has to do with the who else is in the market. Why didn’t Seagate sue Samsung, Intel, BiTMICRO, mTron, Crucial, et al. in addition? Each of these companies have SSD devices (either of their own design or OEM’d from others) that they’re pushing into the market…

b.) Why sue vs. purchase? Interesting concept, at least to me. Knowing that they were somewhat behind the times on this new technology, why didn’t Seagate investigate the potential benefits of purchasing STEC? It makes sense, really. Companies routinely purchase IP in order to gain advantage within the market. With Western Digital buying Komag (and locking up platter manufacturing), why not go down the route of buying your greatest threat? All in all, Seagate easily could have read the writing on the wall and seen where SSDs were going (especially after the EMC Symmetrix announcement!!!!). If Seagate truly wants to protect their shareholders, etc. it would make sense to get into a market segment that promises to be upwards of 8 billion dollars within the next year.

These are my initial thoughts for this morning. Let me know if you have any other ideas.

EDIT: 4/15/08 @ 12:21pm EST

c.) Is Seagate turning into the next Rambus? Sitting in a meeting this morning, I was again trying to review some of the peculiarities of this case (which have been somewhat validated by the statement issued by STEC below). Seagate’s main contention is that STEC violated the following four baseline patents within 3 discrete categories: error correction, memory-backup systems, and storage interfaces with computers. If we follow this particular logic, then, we must assume the following:

  • Seagate developed, controls, and receives royalty payments for: SAS, SATA, Fibre, SCSI interfaces within a given open system AND the signaling technology. (i.e. both physical and electrical connectivity)
  • Error-correcting algorithms are EXCLUSIVE to Seagate and as such, SMART, sector remapping, etc. are exclusive domains of Seagate’s IP.
  • BBUs (battery back up) devices specific to cache within a storage system are proprietary to Seagate and thus subject to oversite and/or royalties, etc.

What’s not really clear here (and mind you, I don’t have access to the patent #’s in questions and their technological backend), is the role of each of the governance boards in this (Fibre Channel Industry Association, SCSI Trade Association). What I find very fishy is that Seagate, being a part of each of these groups, would be allowed to patent something that is an open format (that I am aware) and a trade standard (i.e. Fibre connectivity). If you recall, Rambus did the EXACT same thing by sitting on the DRAM design boards and then backend patenting the technology that was developed. Not saying that Seagate is ultimately a mini-Rambus, but the sheer ferocity in which Seagate seems to be going after STEC is quite suprising.

oh, and in case you missed it, STEC released their counter-statement this morning:

STEC is one of the first companies to build SSDs, having designed, manufactured and shipped SSDs as early as 1994, long before any of the suggested patents were issued to Seagate. Given the effect SSDs are having on the HDD market, STEC believes that Seagate’s lawsuit is completely without merit and primarily motivated by competitive concerns rather than a desire to protect its intellectual property. STEC believes that Seagate’s action is a desperate move to disrupt how aggressively customers are embracing STEC’s Zeus-IOPS technology and changing the balance of power in enterprise storage. Seagate is sending a clear signal that it recognizes STEC as the leader in the SSD business and is attempting to slow down part of the growth that STEC is gaining through its SSD offering, particularly in the enterprise segment. STEC will aggressively pursue its defense to this infringement action.

In addition, STEC will also closely examine the patents asserted by Seagate as STEC believes it held such technology including prior patents, dating more than a decade prior to any of Seagate’s patents. Although STEC is in the process of analyzing the claims in this lawsuit, STEC believes that Seagate’s asserted patents pertain to technologies where STEC has years of prior experience and/or patents. STEC has significant patents related to SSD which have been developed through the decades of experience STEC has with developing, manufacturing and shipping SSDs. Beyond that long history, STEC also believes that many of Seagate’s claims are not relevant to SSD. For example, STEC was one of the originators of stacking technology with patents dating back to the mid-1990s, while Seagate’s patent on this matter was issued in 2005.

Through this process, STEC will determine if Seagate is misappropriating any of STEC’s core technologies; STEC will take appropriate action to protect its interests, including seeking the invalidation of Seagate’s patents.

(emphasis mine)


Add to Technorati Favorites



Obviously, I do actively read and/or manage my blog. To that end, one of the nifty little features of WordPress (and undoubtedly other blogging sites) is the ability to “see” what search terms people are using to land on your blog posts. One of the most fascinating searches had to do with the phrase “Centera vs. Symmetrix.” There are other good search metrics that I’ve seen but I thought I’d delve into this for a second.
Centera vs. Symmetrix
As you’ve undoubtably read before, I did a quick drive-by of the Nextra and in it, promoted the concept that Nextra could become a significant competitor to EMC’s Centera. While this may be slighting the Nextra and Centera somewhat, it does point to the fundamentals of near-line archive being a significant battleground in the coming years. So, to flip this on its head a little, let’s look at the Centera vs. the Symmetrix as wholistic entities dedicated to storing YOUR information.The Symmetrix is a purpose-built, multi-tiered storage system with infinite expandability (well, finite, really, but hyperbole works well, right? ;) ) , connectivity, and AT LEAST 3 tiers of discrete information storage (Tier 0 [SSDs], Tier 1 [fibre], Tier 2-5 [SATA]). The Symmetrix will connect to anything from mainframes to lowly Windows 2003 Servers. It has completely redundant pathways to your data and features a high speed internal bus interconnecting the blades.The Centera is a system based on the RAIN (Redundant Array of Independent Nodes) principle. By itself, the Centera is realistically nothing more than a purpose-built 1U server with specialized policy-based software sitting on top of a very stable Linux OS. (The Centera guys will more than likely want to harm me for distilling it down that far). However, moving the Centera “nodes” from standalone to clusters (aka 4-node “base” units) really changes things and highlights the power of the OS and hardware. Connectivity is limited to IP only (GigE, please!) and the nodes communicate with each other over IP (dedicated private LAN) as well. Not quite as flexible as to the front end connectivity and definitely not the champion of speed by any stretch of the imagination (thanks to SATA drives), but very servicable when using the API to communicate directly. Remember, the Centera is geared toward archive, not Tier 0-3 application sets (though, it appears to function quite well at the Tier 2-5 levels depending on the application).

Hopefully, you’re seeing a pattern here that will answer this particular tag search. If not, here’s the last distillation for you:
: multi-protocol, multi-Tier, high speed storage system
: single protocol, single-Tier, archive storage systemCapiche? ;)

SAS vs. Fibre Challenge

Again, as I’ve pontificated before, I challenge anyone to point out SAS’s shortcomings as it pertains to reliability and performance vs. fibre drives. I see the market turning to SAS as the replacement for Fibre drives and, well, we’ll see where that goes. To that end, I’ve got an interesting challenge for you readers:

The Challenge:
a.) I need someone with a CX3-10 and someone with an AX4-5 base array, with fibre drives and SAS drives respectively.
b.) I need the fibre and SAS drives in a RAID5 4+1 config with a single LUN bound across it (no contention of spindles
c.) I need you to run either the latest version of IOMeter or OpenSourceMark (the FileCopy Utility) against that LUN and report back the information.
d.) I’ll compile the table of data results and, if I receive valid results from multiple people, I’ll send you an EMC t-shirt for your time (to the first responders).Sound like a deal? GREAT!(I’d do it myself but I have no budget for these things…)

Checking out now…


Technorati Tags: , , , , , , , , , , , , , , , , , ,



More on the SAS vs. Fibre debate

by dave on March 25, 2008

Connectivity Reliability

At some point, I had typed in a bit about the physical interfaces present on both the SAS and Fibre drives. I appears that I ran roughshod over that particular point which, upon thinking about it, is a very important dimension of drive reliability.

As noted previously, SAS drives use an amended SATA data+power connectivity schema. Instead of a notch between the data and power connections as present on SATA drives, SAS drives simply “bridge” that gap with an extra helping of plastic. This not only turns the somewhat flimsy SATA connectors into a more robust solution, it also requires that the host connector support that bridging. Interesting note here is that the SAS host connector supports SATA drives but SATA host connectors will not support SAS. This is somewhat assuaged by various host implementations (i.e. using a SAS connector on a backplane with discrete SATA data connectivity from the backplane to the mainboard) but generally, this is the rule. The SAS drives feature a male connectivity block which is mated to a female SAS connectivity block on the host system. Pretty basic stuff.

Fibre drives, on the other hand, use a SCA (single connector edge) medium that is again male on the drive side and female on the host side. Definitely more simplistic in design and implementation (and is featured within all current EMC arrays) and honestly, when push comes to shove, something I would trust inherently more with protection. The same idea is present with SCA80 Ultra320 SCSI drives as well. The fitment here is definitely more secure with less design stress placed on the physical connector (and thusly the PCB itself) than with the SAS solution.

There are always caveats with distinct designs, however, and I’d like to highlight some below.
a.) The SAS data+power connector is inherently MORE secure than the standard SATA interface. Truth be told, I’ve broken SATA data connectors. It’s really not hard since the data connection is a discrete “tab” from the power interface (which I’ve broken as well). The addition of the plastic “bridge” between data and power connections on SAS drives promotes a stronger bond between the connector (whether that be SFF or backplane based) and the drive itself. It also keeps folks from mistakenly connecting SAS drives to SATA ports. 😉
b.) The SAS interface is still prone to breakage as compared to SCA40/80 connections. There’s a reason why we do a conversion within our drive caddies from SATA to Fibre (outside of the obvious protocol translation and sniffer obligations): it’s more secure. The mating mechanism within the SCA interface provides no single point of stress on the connector as there is a nesting process that takes place. Not so with the SAS interface: you have a significant protrusion into the caddy area that, if improperly aligned, can cause damage. If you misalign the SCA interface, you can’t make the connection and there’s no protrusion difficulties.

Note: The good news in all of this (at least from my perspective @ EMC) is that we’re not going to allow you to screw this connectivity up. 😉 We mount the drives in our carriers, put them in the array and, well, we’ve got you covered. 😉

In any case, this is really for further clarification from yesterday’s post. Hopefully that will give a little more food for thought.

Technorati Tags: , , , , , , , , , , , , , , , , ,



SAS vs. Fibre, Seagate’s SSD dilemna, and Sun’s “Freakin’ Laser Beams”

March 24, 2008

SAS vs. Fibre
One thing I hear about constantly (within the hallowed halls of EMC and elsewhere), is the general “inferiority” of SAS drives vs. Fibre. This usually comes complete with a somewhat stale argument that because SAS is a natural extension of SATA, it is therefore a “consumer” drive and not “good enough” for the […]

<br />