First of all, let me start by saying - Props on breaking a million! That was the first thing I noticed when I read that (even before looking at the text and focusing solely on the picture!) You keep it going strong here, with regularly good content fairly consistently. Some times life and other things can get in the way of the blogging so it's nice to see you stick it out and continue (getting better a long the way) I'd be curious to see how that chart looks on a monthly or longer basis, especially in light of the massively successful iPad post you had not too long ago; and what some of your more successful posts have been over that time. It's always good to see when something works and is done well, the continued success which can be built upon that. As always, look forward to more transparent and real content out of you! - Christopher

Should I reach out to my vspecialists?:)

Hi Mike! I am an EMC employee as you know and I know we've infinitely discussed this in explicit detail so much so that I explained, described and defined each and every detail of how I was able to come about these numbers independent of the marketing machine if you will, which is what so encouraged me to publish my findings. Being that you're referencing a blog post in this trend, I'll do the same which was the explanation of how *I* saw these numbers come about and my validation of those facts and figures. http://www.pkguild.com/2010/05/emc-20-unified-storage-guarantee-final-reprise/ However in light of what you're mentioning Mike, let me reiterate what Chuck has brought has mentioned in his comment/reply to you as well. The fact of the matter (note: fact, not caveated promises) is that the EMC storage in question guarantees the customer will save 20% over the competitors unified storage platform. No 'discount' no need for 'details' which can be skewed and torn this way or that depending upon how the wind flows; No. Lay it out side by side, before the EMC storage starts to even leverage any of the -really cool- technology which enables customers to consume less, do far more with fewer spindles, gain performance considerations which are unseen in the industry; No.. before any of that is even taken into considerations; BAM! You're saving 20%! (Booyah I believe is what the customers would be shouting at this point)

Dimitri, I honestly have to say I think it is absolutely adorable and sweet that you are claiming I "exploited a bug on the secalc" whereas, as I stated in my post and as I'll state here, had I KNOWN there was a clear bug, I would have not published what I did as I had found it. This is actually the first time I had ever used the NetApp Space Efficiency calculator in the several years since it was published - Can't blame me for assuming that the data that it would report to me (while I was at NetApp, and now that I am no longer) would be anything but accurate, considering the longevity it has been out there. I do appreciate all of the attention you guys have been paying on this matter, and please do let me know when the calculator has indeed been corrected so I can run through the figures again - considering on both of our sides these are customer public calculators and being that they are intended to reflect an accurate picture of a customers storage needs, I'd like that message to continue to be honest, forthright and true; and not let things like bugs misrepresent the data. Thanks and I look forward to putting this matter to bed! Until that time, I won't have a whole lot to share on this subject! Christopher!

I wrote a lengthy response covering the pro's and con's of the ordeal and offering a succinct clause and reasoning behind why I use facebook. However in the interest of full-disclosure.. the internet took it upon itself to refresh the browser blowing away my comment So end result, I think it important that you not only embrace facebook within the comfort and interest you'd like, but for you to also join my Farm, Cafe and Mafia... It is after all in the best interest of the community. :)

Just to keep things honest, because you know that I love you Vaughn, ;) I want to discuss perhaps what has been overlooked - I'll try not to cover what you've already mentioned (whether right or wrong, so please don't try to u-turn the conversation into something irrelevent to the point I am making, okay ? :)) You mention that the NetApp array is a FAS3160, (Your words: 1 NetApp FAS3160 Array with 16Gbs of cache) but in the Spec report (and how the 3100 series is deployed) it is a cluster (later mentioned in the SPEC report that it is an active/active cluster) [I won't go into how the BOM seems to lack mentioning various required licenses such as cluster and so forth, this doesn't even count! ;)) So subsequently and taken from the SPEC report this is effectively a two node cluster with 8gb of cache (per each controller) and the PAM module which is another 256GB slapped into the mix which is isolated to each node of the cluster, so if I'm doing my math correctly (Please do correct me if I am wrong) 8*2+256*2 = 528 And it has the NVRAM which I honestly don't count, but for the sake of argument in the SPEC report it shows another 2gb per node - for the sum total of 532GB of ram allocated to the system. Please do correct me if I am wrong, that the most amount of memory addressable at a single time on a single node within this configuration is in fact 266 (8+256+2) since the data which is stored on the PAM card is not shared across controllers for accessibility from a connection perhaps going into nodeb in the cluster. (If I am mistaken and the PAMII memory is indeed shared in the Active/Active cluster, where nodea interactively can access the PAMII card of nodeb and vice versa, let me know) But whether that is true/valid or otherwise - please correct me if I am mistaken, but is this 'comparison' report basically saying that this NetApp configuration is using almost 2x the amount of memory that the compared EMC configuration is using? If that being the case, 2x the 'cache' thrown at the problem, but producing 1/2 the speeds/feeds in IOPS (and don't even get me started on how I really don't care about speeds and feeds unless I have a SPECIFICALLY designed app which performs this way in real time and in production (rarely) But putting that aside, as I am exclusiving discussing memory ramifications - and both sides of the coin seem like they deviate from reasonable practice for volume / aggr layout - I won't say how, because I frankly am not sure how the EMC side conforms to best practice, but the Netapp array in this configuration is in violation of 'best practices' (hell, I helped define some of those practices ;)) and I've seen enough disasters to know to NEVER run a prod environment in the exact way the evironment was laid out. So, taking a step back, it's quite possible everything I've said is a bunch of noise (and I'm sure many people on both sides will agree and disagree with everything I've said) My Lessons learned are: Some systems can get really fast speeds (yay?!) and unrealistic expectations without consideration for application behavior can cause us to do crazy things in our environments. People like to write blog posts about their SPEC reports, and people like to write counter blog posts about SPEC reports and sometimes (rarely: me) I typically hate commenting on SPEC reports when there's so much controversy around them, but I couldn't stand idly by with the level of intimate netapp knnowledge I have.. and be... misled perhaps is the word, on the merits of it's own configuration. I guess my follow-up lesson learned on this is, I could rip out everything I've said about the EMC environment, and the points and facts I've made about the NetApp SPEC report and my comments are entirely valid (except for areas I specifically defined as needing confirmation/validation :)) We both know that I know VERY specific ways to make both of these reports fail miserably and one side can shine greater than the other when we take into consideration a 'mixed workdload' as is often the common consideration when it comes to a Unified platform - So we won't open up that can of worms ;) Thanks for your time on this matter Vauhgn and others - and if you disagree with anything I've concretely said or referenced where I may be incorrect or mistaken I welcome the correction; though just like it may be better for me not to post this - It may equally be better not to question the integrity of the facts ;) Oh yea, and don't write comment responses at 130am :) / second comment - the SPEC report you reference for the single FAS6080 - did not link to a valid report [So, I didn't check that in my response] Disclaimer: My comments represent me and my own personal thoughts and opinions, comments, especially for where they're HORRIBLY WRONG AND MISTAKEN, and even where they're OMG RIGHT ;) Subsequently the content here does not reflect the opinions or thoughts of EMC, NetApp, or even SPEC as an organization! - All is fair in love and SPEC reports ~me