Barry Burke

"John - welcome to the conversation! I'm not comparing FAST to existing products - in fact, I've showing how Hitachi's current products don't add up to FAST. Apples to Apples: * Symm Optimizer = Hitachi Volume Migration * Symm Virtual LUN = Hitachi TSM * EMC Information Classification Service = Hitachi Policy Based Management Service * EMC FAST = (crickets) The whole point of this post is that Hitachi sales and marketing are trying to convince customers that the USP already provides FAST, when in fact, it doesn't. You can't simply round up a GUI that presents humans with miles and miles of data and front-end it with a $ervice$ offering and call it FAST. Well, you CAN - but you're not fooling anyone. Repeat after me: FULLY AUTOMATED Storage Tiering. Storage admins don't have the time to monitor the performance of tens of thousands of LUNs, nor the ability to analyze all that data to make optimal decisions about where to place what - nor should they have to. Thus the practical solution..." - Barry Burke

"Guilty, as charged. :o>" - Barry Burke

"You presume that Symmetrix does not enjoy the benefits of “newer architectures”, but in fact, Virtual Provisioning is indeed a considerably different infrastructure for data storage. It truly virtualizes the data storage layer beneath it, and in fact has many of the attributes of what you would consider “new architecture.” And indeed, as BarryW says, it’s not the movement (or avoidance of movement) that’s so hard…it’s figuring out what needs to be moved when and where. EMC has been working on FAST for even longer than the announced date, analyzing traces from literally thousands of installed arrays and modelling different prefetch algorithms. And an almost equivalent amount of time and effort has gone into the definition of the management interfaces for FAST, leveraging a half dozen or so customer Technical Advisory Panels where different approaches have been modelled and analyzed by future FAST users. And it really isn’t a race to see who’s first; I’ll safely predict that FAST-like..." - Barry Burke

"And to clarify, FAST algorithms have to adjust for the fact that some data is more efficiently cached a) at the server, and b) in the array cache. Accomodating the fact that that these (faster) caches exist up-stream has a defiitive impact on the FAST management algorithms. It’s all about minimizing latency on predictable cache misses…" - Barry Burke

"Chris – I see you’re having some fun speculating over FAST implementation and strategies… I don’t think you’re really thinking this all the way through, though. The objective of promotion to a faster type of storage isn’t as simple as to try to stick the most recently requested data onto the fastest storage – heck – that would frequentrly be a waste of good Flash, because lots of data is accessed once and never again. No, the objective of FAST is to get the data that most often (and repeatedly) results in long response times when it requested over a period of time promoted – and to get that data promoted BEFORE it is even requested. Thus, the secret of FAST is to PREDICT what needs to be in Flash, and to determine what can safely be demoted to slower storage without significantly impacting response times – and then to get that data there at the right time. I can’t get into all the details here (patents and all that), but the simple LRU scheme you describe simply isn’t sufficient for..." - Barry Burke

"You do realize that Nintendo stopped using the MIPS chip when they built the Wii, don't you? And the Wii uses...YOU GUESSED IT: the PowerPC!!!" - Barry Burke

"@K.T. - Thanks for taking this post in the spirit it was intended - all in good fun! ;o)" - Barry Burke

"TimC - Nowhere did I say that the DS8K is dead. Just observed that IBM is making FAR more noise about the SVC's flash integration than about the DS8K. Maybe it's just BarryW's enthusiasm, but you gotta admit that every one else has been silent about the DS8700 - almost as if they're embarrassed to acknowledge it?" - Barry Burke

"While indeed FAST v1 essentially does what you can do manually, it automates the process – indeed, similarly to what Symm Optimzier does (although Symm Optimizer does not move across different types/speeds of drives). But FAST introduces the notion of Policies, allowing storage admins to define different porportions of Flash, FC and SATA for different applications. And this Automation is indeed the value proposition; many customers today complain that they don’t have the people or time required to determine the appropriate tiering for either their current or their new applications; this leaves many using the de-facto 15K rpm drive as their platform, when either Flash or SATA (or a mix) might be more cost-effective for both CAPEX and OPEX. I’ll defer the pricing discussion until after GA announcements later this quarter. And the patent topic really isn’t something I can comment upon at this time." - Barry Burke

"Robin, You are absolutely correct – there are many places that are susceptible (sic?) to data corruption. Most communications and I/O protocols generally provide adequate protection, however – there are CRC’s and verification in almost every layer of FCAL, SCSI, IP, TCP, UDP, iSCSI, FCOE, DCE, WiFi, (ad infinitum). But if shortcuts are taken in the implementation, particularly where data must cross from one domain (or layer) to another, SEUs and indeed cosmic particles can (and often do) corrupt data. Most of these get detected and the protocol forces a retry/retransmit, so nothing bad happens. Many of today’s SSDs are in fact not really considered enterprise-class by the array vendors because of unprotected data paths and incomplete integrity checks as data moves from the I/O controller through FPGA/ASIC into DRAM and eventually down to the NAND cells. But indeed, the risks are just about everywhere, and it is often difficult to identify them without analysing logic diagrams and the..." - Barry Burke

"Symmetrix has used ECC-protected DRAM for years, and it actively tracks and reports back to EMC even the corrected errors. But ECC alone is not trusted as sufficient protection- within Symmetrix DRAM, data blocks are striped across multiple chips with additional check bytes (Hamming codes, iirc, not simple CRC) capable of detecting and correcting multi-bit errors. Together, these form a belt-and-suspenders approach to protecting data integrity in memory. Additionally, Symmetrix protects data with verified guard bytes all along the I/O path, from the front-end ports all the way through to drives, and back again – integrity is verified and the protection bytes regenerated every time data moves across different “domains” in the I/O path.. Beginning with V-Max, we take this one step further: an (8-byte) T10-DIF guard is generated for each 512-bytes of data upon receipt from the server, and this is carried through all the way to be stored on the disk along with the data; these check bytes..." - Barry Burke

"Sour grapes? I have nothing to be bitter about! Nope, I'm simply observing that there's nothing all that special about being able to reclaim unused space in thin devices. Oh, yeah. I am also reminding the audience that your track record about what is really important (and what isn't) ain't really all that good...tell us, if wide-striping is the be-all and end-all to storage performance, then why dost thine president bespeak of a future with Flash drives embeddeth in thine arrays? Perhaps 'tis thou, good sir, with the sour taste in thine mouth?" - Barry Burke