EMC 20% Unified Storage Guarantee !EXPOSED!

May 20th, 2010
by Christopher Kusek (PKGuild)

The latest update to this is included here in the Final Reprise! EMC 20% Unified Storage Guarantee: Final Reprise

For those of you who know me (and those who don’t, hi! Pleased to meet you!) I spent a lot of time at NetApp battling the storage efficiency game, always trying to justify where all of the storage space went in a capacity bound situation.   However since joining EMC, all I would ever hear from the competition is how ‘space inefficient’ we were and frankly, I’m glad to see the release of the EMC Capacity Calculator to let you decide for yourself where your efficiency goes.   Recently we announced this whole "Unified Storage Guarantee" and to be honest with you, I couldn’t believe what I was hearing. So I decided to take the marketing hype, set it on fire and start drilling down into the details, because that’s the way I roll. :)

EMC Storage Guarantee

I decided to generate two workload sets side by side to compare what you get when you use the Calculators

I have a set of requirements – ~131TB of File/Services data, and 4TB of Highly performing random IO SAN storage

There is an ‘advisory’ on the EMC guarantee that you have at least 20% SAN and 20% NAS in order to guarantee a 20% space efficiency over others – So I modified my configuration to include at least 20% of both SAN and NAS (But let me tell you, when I had it as just NAS.. It was just as pretty :))

Using NetApp’s Storage Efficiency Calculator I assigned the following data:

Storage Efficiency Calculator

That seems pretty normal, nothing too out of the ordinary – I left all of the defaults otherwise as we all know that ‘cost per TB’ is relative depending upon any number of circumstances!

So, I click ‘Calculate’ and it generates this (beautiful) web page, check it out! – There is other data at the bottom which is ‘cut off’ due to my resolution, but I guarantee it was nothing more than marketing jibber jabber and contained no technical details.

Storage Efficiency Calculator

So, taking a look at that – this is pretty sweet, it gives me a cool little tubular breakdown, tells me that to meet my requirements of 135TB I’ll require 197TB in my NetApp Configuration – that’s really cool, it’s very forthright and forth coming.

What’s even cooler is there are checkboxes I can uncheck in order to ‘equalize’ things so to speak. And considering that the EMC Guarantee is based upon Useable up front without enabling any features! Let me take this moment to establish some equality for a second.

Storage Efficiency Calculator

All I’ve done is uncheck Thin Provisioning (EMC can do that too, but doesn’t require you to do that as part of the Guarantee, because we all know… some times… customers WON’T thin provision certain workloads, so I get it!)   Also turning off deduplication, just so I get a good feel for how many spindles I’ll be eating up from a performance perspective – And turning off dev/test clone (which didn’t really make much difference since I had little DB in this configuration)

Now, through no effort of my own, the chart updated a little bit to report that NetApp now requires 387TB to manage the same workload a second ago required 197TB. That’s a little odd, but hey, what do I know.. This is just a calculator taking data and presenting it to me!

Now… with the very same details thrown into the EMC Capacity Calculator, lets take a look at how it looks.


According to this, I start with a Raw Capacity of ~207TB and through all of the ways as defined on screen, I end up with 135TB Total usable, with at least 20% SAN and about twice that in NAS – Looks fairly interesting, right?

But lets take things one step further. Let’s scrap Snapshots on both sides of the fence. Throw caution in to the wind.. No snapshots.. What does that do to my capacity requirements for the same ~135TB Usable I was looking for in the original configurations.

clip_image005[4]I updated this slide to accurately reflect more realistic R5 sets for the EFD disks.  In addition I introduced an ADDITIONAL spare disk, which should 'hurt' my values and make me appear less efficient.

On the NetApp side I reclaim 27TB of Useable space (to make it 360TB Raw)- while on the EMC side I reclaim 15TB of useable space [150TB Useable now] while Still 207TB Raw.

But we both know the value of having snapshots in these file-type data scenarios, so we’ll leave the snapshots enabled – and now it’s time to do some math – Help me as I go through this, and pardon any errors.

Configuration NetApp RAW NetApp Useable Raw v Useable % EMC RAW EMC Useable Raw v Useable % Difference
Default Checkboxes   197 TB 135 TB 68% 207 TB 135 TB 65% -3%
Uncheck Thin/Dedup   387 TB 135 TB 35% 207 TB 135 TB 65% +30%
Uncheck Snaps   369 TB 135 TB 36% 207 TB 150 TB 72% +36%

However, just because I care (and I wanted to see what happened) I decided to say "Screw the EMC Guarantee" and threw all caution to the wind and decided to compare a pure-play SAN v SAN scenario, just to see how it’d look.


I swapped out the numbers to be Database Data, Email/Collaboration Data – The results don’t change (Eng Data seems to have a minor 7TB Difference.. Not sure why that is, – feel free to manipulate the numbers yourself though, it’s negligible)


And I got this rocking result! (Yay, right?!) 202TB seems to be my requirement with all the checkboxes checked! But this is Exchange and Sharepoint data (or notes.. I’m not judging what email/collab means ;))… I’m being honest and realistic with myself, so I’m not going to thin provision or Dedup it any way, so how does that change the picture?


It looks EXACTLY the same [as before]. Well, that’s cool, at least it is consistent, right?

However, doing the same thing on the EMC side of the house.

I want to note a few differences in this configuration – I upgraded to a 480 because I used exclusively 600GB FC drives as I’m not even going to lie to myself that I’m humoring my high IO workloads on 2TB SATA Disks – If you disagree you let me know, but I’m trying to keep it real :)

RAID5 is good enough with FC disks (If this was SATA I’d be doing best practice and assigning RAID6 as well, so keeping it true and honest) And it looks like this:


(Side Note: It looks like this SAN Calculation has only 1 hot spare declared instead of the 6 used above in the other configuration – I’m not sure why that is, but I’m not going to consider 5 disks as room for concern so far as my calculations go – it is not reflected in my % charts below – FYI!  I fixed the issue and introduced 6 Spare disks.  I also changed the system from 14+1 R5 sets to 4+1 and 8+1 R5 sets which seems to accurately reflect more production like workloads :))

Whoa, 200TB Raw Capacity to get me 135TB Usable? Whoa, now wait a second. (says the naysayers) You’re comparing RAID5 to RAID6 – that’s not a fair configuration because there is definitely going to be a discrepancy! And you have snapshots enabled too for this workload. (Side note: I do welcome you to compare RAID6 in this configuration, you’ll be surprised :))

I absolutely agree – so in the effort of equalization – I’m going to uncheck the Double Disk Failure Protection from the NetApp side (Against best practices, but effectively turning the NetApp configuration into a RAID4 config) and I’ll turn off Snapshot copies to be a fair sport.


There, it’s been done. The difference is.. That EMC RAW Capacity has stayed the same(200TB) while NetApp raw capacity has dropped considerably by 30TB from 387TB to 357TB. (I do like how it reports "Total Storage Savings – 0%" :))

So, what does all of this mean? Why do you keep taking screen caps, ahh!!

This gives you the opportunity to sit down, configure what it is YOU want, get a good feel for what configuration feels right to you and be open and honest with yourself and said configuration.

No matter how I try to swizzle it, I end up with EMC coming front and center on capacity utilization from RAW to Usable – Which down right devastates anything in comparison. I do want to qualify this though.

The ‘guarantee’ is that you’ll get 20% savings with both SAN and NAS. Apparently if I LIE to my configuration and say ‘Eh, I don’t care about that’ I still get OMG devastatingly positive results of capacity utilization. – So taking the two scenarios I tested in here and reviewing the math..

Configuration NetApp RAW NetApp Useable Raw v Useable % EMC RAW EMC Useable Raw v Useable % Difference
Default Checkboxes   197 TB 135 TB 68% 207 TB 135 TB 65% -3%
Uncheck Thin/Dedup   387 TB 135 TB 35% 207 TB 135 TB 65% +30%
Uncheck Snaps   369 TB 135 TB 36% 207 TB 150 TB 72% +36%
Default Checkboxes   202 TB 135 TB 67% 200 TB 135 TB 68% +1%
Uncheck Thin/Dedup   387 TB 135 TB 35% 200 TB 135 TB 68% +33%
Uncheck RAID6/Snaps   357 TB 135 TB 38% 200 TB 151 TB 76% +38%

When we’re discussing apples for apples – We seem to be meeting the guarantee whether NAS, SAN or Unified.

If we were to take things to another boundary, out the gate I get the capacity I require – If I slap Virtual Provisioning, Compression, FAST Cache, Auto-Tiering, Snapshots and a host of other benefits that the EMC Unified line brings to solve your business challenges… well, to be honest it looks like you’re coming out on top no matter what way you look at it!

I welcome you to ‘prove me wrong’ based upon my calculations here (I’m not sure how that’s possible because I simply entered data which you can clearly see, and pressed little calculate buttons… so if I’m doing some voodoo, I’d really love to know)

I also like to try to keep this as realistic as possible and we all know some people like their NAS only or SAN only configurations. The fact that the numbers in the calculations are hitting it out of the ballpark so to speak is absolutely astonishing to me! (Considering where I worked before I joined EMC… well, I’m as surprised as you are!) But I do know the results to be true.

If you want to discuss these details further, reach out to me directly (christopher.kusek@emc.com) – or talk to your local TC (Or your TC, TC Manager and me in a nicely threaded email ;)) – They understand this rather implicitly.. I’m just a conduit to ensure you folks in the community are aware of what is available to you today!

Good luck, and if you can find a way to make the calculations look terrible – Let me know… I’m failing to do that so far :)

!UPDATE! !UPDATE! !UPDATE! :)  I was informed apparently every thing is not as it seems? (Which frankly is a breath of relief, whew!)

Latest news on the street is, apparently there is a bug in the NetApp Efficiency Capacity Calculator – So after that gets corrected, things should start to look a little more accurate, let me breathe a sigh of relief around that, because apparently (after being heavily slandered for ‘cooking the numbers’) the only inaccuracy going on there [as clearly documented] was in the source of my data.

However, being that I’m not going to go through and re-write everything I have above again, I wanted to take things down to their roots, lets get down into the dirt, the details, the raw specifics so to speak.  (If any thing in this chart below is somehow misrepresented, inaccurate or incorrect, please advise – This is based upon data I’ve collected over time, so hash it out as you feel :))

NetApp Capacity GB TB EMC Capacity GB TB GB Diff TB Diff % Diff
Parity Drives 4000 3.91   Parity Drives 4000 3.91 0 0  
Hot Spares 1000 0.98   Hot Spares 1000 0.98 0 0  
Right Sizing 3519 3.44   Right Sizing 1822.7 1.78 1696.3 1.66  
WAFL Reserve 2045.51 2   CLARiiON OS 247.87 0.24 1797.64 1.76  
Core Dump Reserve 174.35 0.17   Celerra OS 60 0.06 114.35 0.11  
Aggr Snap Reserve 863.06 0.84     0 0 863.06 0.84  
Vol Snap Reserve – 20% 3279.62 3.2   Check/Snap Reserve 20% 3973.89 3.88 -694.27 -0.68  
Space Reservation 0 0     0 0 0 0  
Usable Space 13118.5 12.8 Usable Space 16895.54 16.49 -3777.04 -3.69 +23%
Raw Capacity 28000 27.34 Raw Capacity 28000 27.34 0 0  

What I’ve done here is take the information and tried to ensure each one of these apples are as SIMILAR as possible.

So you don’t have to read between the lines either, let me break down this configuration – This assumes 28 SATA 1TB Disks, with 4 PARITY drives and 1 SPARE – in both configurations.

If you feel that I somehow magically made numbers appear to be or do something that they shouldn’t – Say so.   Use THIS chart here, don’t create your own build-a-config workshop table unless you feel this is absolutely worthless and that you truly need that to be done.   

You’ll notice that things like Parity Drives and Hot Spares are identical (As they should be) Where we start to enter into discrepancy is around things like WAFL Reserve, Core Dump Reserve and Aggr Snap Reserve – Certainly there are areas of overlap as shown above and equally the same can be said of areas of difference, which is why in those areas on the EMC side I use that space to define the CLARiiON OS and the Celerra OS.    I did have the EMC Match the default NetApp Configuration of a 20% vol snap reserve (on the EMC side I call it Check/Snap Reserve) [Defaults to 10% on EMC, but for the sake of solidarity, what’s 20% amongst friends, right?]    (On a side note, I notice that my WAFL Reserve figures might actually be considerably conservative as a good friend gave me a dump of his WAFL Reserve and the result of his WAFL Reserve was 1% of total v raw compared to my 0.07% calculation I have above, maybe it’s a new thing?)

So, this is a whole bunch of math.. a whole bunch of jibber jabber even so to speak.   But this is what I get when I look at RAW numbers.   If I am missing some apparent other form of numbers, let it be known, but let’s discuss this holistically.     Both NetApp and EMC offer storage solutions.    NetApp has some –really- cool technology.  I know, I worked there.   EMC ALSO has some really cool technology, some of which NetApp is unable to even replicate or repeat.   But before we get in to cool tech battles, as we sit in a cage match watching PAM duel it out with FAST-Cache, or ‘my thin provisioning is better than yours’ grudge matches.    We have two needs we need to account for.

Customers have data that they need to protect.   Period.

Customers have requirements of a certain amount of capacity they expect to get from a certain amount of disks.

If you look at the chart closely, there are some OMFG ICANTBELIEVEITSNOTWAFL features which NetApp brings to bear, however they come at a cost.   That cost seems to exist in the form of WAFL Reserve, and Right sizing (I’m not sure why the Right Sizing is coming in a considerably fat consideration when contrasted with how EMC does it, but it apparently is?)  So while I can talk all day long about each individual specific feature NetApp has, and equivalent parity which EMC has in that same arena; I need to start somewhere.  And strangely going back to basics, seems to come to a 23% realized space savings in this scenario (Which seems inline with the EMC Unified Storage Guarantee) Which frankly, I find to be really cool.  Because like has been resonated by others commenting on this ‘guarantee’, what the figures appear to be showing is that the EMC Capacity utilization is more efficient even before it starts to get efficient (through enabling technologies).

Obviously though, for the record I’m apparently riddled with Vendor Bias and have absolutely no idea what I’m talking about! [disclaimer: I have no idea what I’m talking about when I define and disclose I am in this post and others ;)]   However, I’d like to go on record based upon these mathematical calculations, were I not an employee of EMC, and whether I did or did not work for NetApp in the past, I would have come to these same conclusions independently when presented with these same raw figures and numerical metrics.   I continue to welcome your comments, thoughts and considerations when it comes to a Capacity bound debate [Save performance for another day, we can have that battle out right ;)]  Since this IS a Pureplay CAPACITY conversation.

I hope you found this as informative as I did taking the time to create, generate, and learn from the experience of producing it.  Oh, and I hope you find the (unmoderated) comments enjoyable. :)   I’d love to moderate your comments, but frankly… I’d rather let you and the community handle that on my behalf.   I love you guys, and you too Mike Richardson even if you were being a bit snarky to me. {Hmm, a bit snarky or a byte snarky… Damn binary!}  Take care – And Thank you for making this my most popular blog-post since Mafia Wars and Twitter content! :)

The latest update to this is included here in the Final Reprise! EMC 20% Unified Storage Guarantee: Final Reprise

Tags: , , , , , , ,
Posted in Celerra, CLARiiON, Deduplication, Efficiency, emc, FAST, NetApp, SSD, Storage | Comments (38)

  • […] This post was mentioned on Twitter by Christopher Kusek and Chuck Hollis, EMC Chicago. EMC Chicago said: RT @cxi: {blog} EMC 20% Unified Storage Guarantee !EXPOSED! http://bit.ly/aMDzc7 […]

  • Jonas Irwin says:

    Great write up and thanks for putting it to the test! Looks like you've been through the same steps that we went through creating this. It's nice that our guarantee doesn't have 96 pages of caveats :-).

  • Nick Triantos says:

    Hey Chris…

    Your example seems “normal” to someone who's in the business for creating non-intelligent Application silo's…So I have a few simple questions for you.

    How many NetApp customers do you that:

    a) Do not use Snapshots
    b) Don't use clones (Flex or Lun Clone)
    c) Do not use deduplication, even for part of their data
    d) Deploy only Home Dirs
    e) Do not deploy Databases, Virtual servers, in combination with NAS data
    f) Is an EMC RAID 5 14+1 configuration, a typical, or a best practice config, for ANY EMC storage array. Reading at Best practices this does not seem to be the case. That's not to say that it can't be done or it's not supported, but does a typical EMC customer use a 14+1 RAID 5 RAID Group? I think we both know the answer to this…

    Essentially what you have shown is how to make NetApp array look like a dumb box of disks in order to compare it to a less intelligent architecture. I must admit you do have the upper hand…

    What i'd really like to see is, and i'm sure you readers would too, is not a comparison between Raw/ Usable but rather a comparison of the Overall Storage Efficiency between the 2 arrays given that at the end of the day, customers do use snapshots, clones, flexclone and deduplication with NetApp, and generally speaking, they are more interested in the utilization and efficiency of their storage infrastructure as it pertains to their day-to-day operations and their needs. At least our customers do…

    So let me ask you this, If EMC provides X TB usable and NetApp 20% less, and NetApp turns on dedup, snapshots and clones who do you think a customer will consider more efficient? The one who sold him 20% less usable storage but saves him at least 2x of additional capacity thru intelligent techniques to accomplish their day to day business needs, or the one who sold him 20% more usable storage?

    I, also, find it bizarre that you talk about space efficiency techniques like thin provisioning, snapshots, compression, yet you provide comparisons of Raw/Usable. I think your readership would be most interested on more important things like what their costs will be over time in terms of managing distinct architectures, how efficient the architecture is in terms of *storing* the data, and what their savings will be.

    Btw…Howcome a “Unified Storage” uses disks for 2 separate Operating Systems?

  • DrDedupe says:

    Hi Chris I must have missed someting, sounds like you are saying as you turn off NetApp's efficiencies it begins to look more and more like an EMC system, am I reading this right?


  • JK says:

    Nick – GREAT points…

    Except for one thing, that's 20% efficient BEFORE they turn on the efficiency.

    What is that you ask? Well, Checkpoints (snaps), thin provisioning, Fully Automated Storage Tiering at the sub-LUN level, live file system deduplication AND compression (not only file shares but individual VMs).

    What button do I click on a filer to dedup a virtual machine again?

    So all of those things you mentioned are very important to most IT organizations. Although the names are different, it seems that the EMC Array has all of the features you mentioned.

    All of this from a single, VMWare enabled interface that provides visibility to the disk level to a VMWare admin from the VI client while at the same time providing VM level visibility to the Storage Admin.

    Efficiency is much more than just $$ per gigabyte – but if we're using that yard stick, EMC is 20% more efficient out of the box BEFORE they start getting efficient.

    You might want to check out the demos:


  • D Landes says:

    Maybe you guys from EMC missed it but Network Appliance not only has a Guarantee program but it's a 50% Guarantee.


    Isn't 50% more savings than 20%? Nice try EMC looks like David kicked Goliath's butt again!

  • John Martin says:

    I thought I'd run some comparisons of my own using the sizers that the engineers use.

    If you start with 210 TB (RAW SNIA Base-10 TB) on a NetApp array with one hot spare and no snapshots and RAID-4 (same as your final FIle+DB example), you end up with 155.726 TiB (Base-2 Usable Tibbibytes, which I think you've shown as TB on your example). This works out to 73.8% which is a little better than your best case figures for your “Unified Storage”

    Of course this is a completely bogus configuration. The people I've met from EMC care about their professional reputations and their customers data, and I strongly doubt any of them would ever reccomend or implement a configuration like that. It's interesting marketing, but completely divorced from the real world.

    As far as the email/collab figures go I assume you're configuring this in a traditional SAN configuration.

    The interesting thing about these traditional SAN's configurations is that they have a long history of being terribly wasteful in the way storage is allocated, with typical figures of 40% of the space being wasted/unused/overallocated in little LUN based islands of storage. It is this 40% figure that we assume will persist in our configuration as well as that of other offerings unless you use techniques like thin provisiong. It seems like the way you are using your sizer assumes that people will use their storage with 100% efficiency. If you take this out of the equation, your purported 40% advantage simply isnt there.

    Of course going with a traditional SAN configuration will save you about 10% vs a more modern deployment Dart/Ontap due to the in built space reservations included to provide fine grained storage virtualisation. Fair enough, but the world has moved on, and to get the advantages of dedup, and compression and cloning, and thin provisioning, and high performance snapshots, you generally have to give a little capacity to the storage virtualisation layer to make this work gracefully.

    You could also argue that you should be sizing these solutions based on IOPS, not just capacity, but if we did that, we'd probably be looking at SATA for Exchange 2010. If you want to tell customers to do old school thick provisioning for sharepoint without using any storage efficiency features thats fine by me, but dont be surprised when you lose deals to NetApp.

    If you'd like to put up something resembling a real customer requirement including IOPS and data protection requirments, I'd be happy to size up something for you. In the mean time, keep an eye out for the next revision of our storage efficiency calculators.

  • Nick Triantos says:


    I may make some Great points but you didn't really respond to any of them and took the high road, nor did you provide any evidence as to what storing data efficiently on an EMC array looks like as compared to NetApp or anyone else for that matter, with your space efficiency features turned on.

    You can't now claim storage efficiency is more than $/Gb, when your entire post, the entire guarantee, is based on based on usable space which insinuates better cost per usable Gb…initially from everyone else.

    BTw…You don't have to click a button on our Array to dedup..All you need to do is click a button in vCenter. :-)

    That said, I would agree that Storage efficiency is about more than $/G. It's about broadly shared truly unified infrastructures that can host all applications, all projects, all tenants, that can be virtually partitioned in a secure manner, that can scale up or down, that do not require rip and replace to scale, that do not use different set of processes to install, maintain, configure, and upgrade.


  • Jonas Irwin says:

    Bottom line: “EMC is more efficient before we even start getting efficient”

    Maybe EMC should have created a real 300% savings guarantee based on telling customers to over provision their luns and file systems by 300X with EMC thin provisioning? Perhaps that would be more valid :-)? Extreme example..but hopefully that illustrates the point here.

    Funny how ntap folks try to change the subject and point to their layered technologies to turn the attention away from the massive space deficit that their customers must start with on their kit, particularly in the block storage world. Yes, there are editorial docs about turning off all system safety nets but they are there for a reason. How about “If you want more space savings out of the gate, we can auto delete your backups..(ouch)”. Any vendor can rig a guarantee and draft nearly 100 pages of confusing caveats to achieve an artificial savings number compared to something that rarely exists in the real world– for example an all RAID 1/0 config. 80% of the RAID sets on EMC systems run RAID 5 and enjoy more than 5x9s because of proactive hot-sparing , checksum and sniffer technologies. On a JBOD, double disk failure happens with R5 but I’ve never seen even so much as a parity rebuild happen on a CX3 (or above) platform in my 3 years here. We can do RAID 6 too and hit the number just fine as well. To derive savings out of dedupe to meet their imaginary guarantee numbers, customers must delete or exclude all database data, encrypted or image data that is beyond 10% (or is 20%?) of their total data set. Is that where some of the space savings is coming from ;-)?

    The idea with the EMC guarantee is simple..use system defaults and achieve 20% or better savings without earning a PhD from vendor caveat school ?. EMC is taking a “customer first” approach that prevents us from forcing the customer to become an expert in understanding a litany of so many confusing caveats (96 pages), that they just give up. Why not just allow the customer to power the box up, create some file systems and luns and get massive savings out of the gate? From there, they can absolutely layer on thin, dedupe, compression and FAST to achieve orders of magnitude more savings. In fact, to achieve a even better number EMC midrange system allow customers to consolidate 3 different types of disk into a single pool. From there FAST will autonomically balance the workload for space and performance with a simple, easy to use policy. Not all apps are thin friendly, not all apps and data compress or dedupe well, so the only way to unequivocally guarantee a savings number around those features is by adding a mountain of caveats. The more caveats you have, then more customer agnst and confusion results. Forget it..it’s a waste of everyone’s time! If you're starting from a much more efficient base, you don't have to force your customer to exclude data sets, figure out how and when to run post processes like dedupe across say, 200 volumes. Also, aren’t snapshots and writable snaps included in their savings number (when compared to full clones) but it’s operationally very complex to have both dedupe and snapshots on the same volume without cancelling out the benefit of either. This ends up being an “OR” rather than an “AND”. I can’t mention the names of the large list of customers who’ve found the EMC gaurentee refreshing just yet, but there are more than I can count on 4 hands right now ;-)

  • Chris,

    Your post is clearly incorrect and I've posted a reply on my blog. I do hope, after gathering more information, you decide to clear up some of the misinformation you have shared here; for the sake of your own credibility. Otherwise, this post will become an example of the lengths EMC will go to mislead customers.


  • Jonas Irwin says:

    John – are you saying that ntap guarantees are real world and take both performance and capacity into consideration?

  • Jonas Irwin says:

    D Landes – I would argue that no customer uses that config with all those constraints. It's also compared to all R1/0 with all thick provisioning and massive under subscription. Sounds like you don't really understand the features available on a modern EMC midrange system. Time to update your competitive decks over there ;-)

  • Jonas Irwin says:

    Why does it matter if emc has two operating systems – one for nas and one san if all customer requirements can be met and they are all managed through a single pane of glass?

  • Thanks for mentioning/noticing the 14+1 R5 sets. I accidentally clicked on that while generating these – so I've corrected it inline in both the images as well as the calculations for EMC efficiency! In it's place I've used a combination of 4+1 and 8+1 R5 sets, including increasing the number of hot spares from 1 (in the SAN scenario) up to 6, and from 6 in the NAS scenario up to 7 – So that should negatively impact my figures making my capacity metrics go down by a small margin!

    However, answering your question chronologically.

    I know of numerous NetApp customers who would not use Snapshots, equally would also not use clones (certainly there are customers who also use Flexclones as well, but the same can be said of EMC customers who use BCV's – strangely.. that is not what I'm discussing here… this is a capacity out of box question.. carrying on)

    I know of several extremely large NetApp customers who do not use Deduplication for a SINGLE portion of their data – so to answer that question (Yes I do know)

    I honestly wasn't even really looking at things from a 'home directory' perspective, more than half the data I'd be dealing with would be NFS datasets, CIFS data (not being used as Home Dirs) and LUN's presented via iSCSI (or FCP in some cases)

    Addressing your question on E – It really depends upon the environment, but certain silo'd environments prefer not to mix their data certainly – I'd prefer that they did but then certain risks come up especially as data crosses boundaries and you run into Kahuna limitations (which was always extremely painful)

    As I stated above – I've modified/Fixed F and the updated images should be inline as well as the calculations (with comments noting the changes as I'm not trying to pull the 'wool' over any ones eyes. To be honest, I took the calculators at face value, *I* have made absolutely no assumptions what so ever in here!

    Essentially (sadly and fearfully) it's actually the NETAPP Calculator which makes the Netapp array look like a dumb box of disks. I STILL calculate netapp storage on a whiteboard, that's how I've always done it and likely will continue that way for some time – I didn't even think of writing this blog post until I saw just how devastating the results the NetApp calculator seemed to reveal. I always knew that raw v available was off due to complaints from customers, but I never really realized nor saw just how bad it was until using the calculator and accounting for the extremely and very real customer use case where 'thin provisioning' wasn't even remotely a reality for their OLTP or high change rate systems.

    I'll work on getting you a over-all comparison of efficiency when enabling all of the other features under the sun (it's a little challenging to do that without having a netapp system and an EMC system side by side with the exact same set of data on them, provisioned similarly and with all of the features like thin provisioning, etc turned on) – So considering the almost equality of all of the 'features' to effectively be similar on both sides, when I come back to RAW – EMC seems to be coming out on top; This is not me saying that, but instead the numbers are coming back and reflecting that.

    I appreciate your comments and taking your time to read and comment on my post.

    I look forward to hearing more from you on this and other subjects.

  • Nick Triantos says:

    Why? Well lets see…

    1) Because you need a few different ways to replicate depending on what protocol you are using
    2) Because different ways to obtain snapshots depending on the protocol
    3) because there are different processes to patch each side which is more time consuming
    4) because each product has its own separate volume management and space is split between the NAS/SAN function making it almost impossible to reduce one and allocate it to another
    5) Because fault isolation and troubleshooting can become more complex when dealing with disparate architectures that have been tied together
    6) Some important features are only available for the NAS side only and maybe iSCSI

    All of the above contribute to increasing customer Operational expenses. A single pane of glass, while a valuable tool, does not eliminate the fact that customers are dealing with disparate architectures.

  • Jonas says:

    Nick – those gaps are rapidly closing now although I would agree it's not 100% ideal for all use cases. Thin, dedupe, volume management, and compression are available on both sides (file+block) and are now based on the same code base (dart 6 and flare 30 in july).. I will hold off on discussion of snapshots but today there is a delta between the two as you point out..so I'll give you that..but don't expect emc to stand still there :-).

    There are still pros and cons to both approaches. Patching has been automated and is customer installable from beginning to end..By rolling nas updates across a single node at a time, the overall impact during an ndu is lessened to fewer areas from a performance standpoint..

    Another nice thing about isolation of nas from san is that if your nas goes down for whatever reason, your SAN stays up. Scaling up to 7 active blades allows customers to add NFS and CIFS horsepower independent of upgrading the entire array head or prematurely adding another separate array alongside it and creating another management island.

    Ultimately multi-tiered pools with mostly sata, some fc and a small amount of efd, thin, dedupe and compression, and auto-tiering drives efficiencies very differently than ntap..but emc arrives at the efficiency goal nonetheless. It's probably tempting for ntap to continue to compare themselves to traditional old school, all R10 provisioning models that are indeed very wasteful. If emc doesn't recommend provisioning models like that anymore, where does that leave all the claims about massive ntap savings relative to emc..

  • Chuck Hollis says:

    Just checked over here, and — boy! — are some people pretty worked up. All I can do for the NetApp folks is share some advice — when you're in a hole, stop digging!

  • Scott says:

    This two operating system argument is getting sort of boring. We've heard this for years and it's really pretty dull at this point.

    It's kind of like EMC saying “hey, we have 15 drives per disk tray and the other guys only have 14”!

    That's not a technical advantage, it's an architectural difference. Sometimes it makes sense to have a couple of little pieces of software that are tuned for a specific task, and other times it makes sense to have everything in one single OS. It depends on what your goal is. Simplicity makes sense, but do you compromise performance or availability with one OS that attempts to do everything on one set of processors? EMC customers won't stand for that, and neither will EMC engineering.

    So if you don't have a performance problem (when the system gets busy), the big question is, from a business perspective, does it really matter?

    Now, if your argument is that you have to use two completely different tools to manage one system, then perhaps (even though it really isn't rocket science) you have an argument.

    In the filer world, if I have a cluster, I have to go to two different screens to manage each filer. No big deal, but yeah, two interfaces. In the old NS models, you have to go to a NAS tool to setup file systems and the SAN tool to set up LUNs. Still not rocket science, but I guess it's an argument. If you have a couple of little storage arrays in your world, I submit it's really no big deal. However, if you run an enterprise shop with lots of storage to manage and lots of admins to train, not it's more difficult.

    Customers asked for something more simple. EMC agreed that this was a great idea and has designed Unisphere, a single simple way to manage not only storage in the traditional NAS and SAN world but also links into other critical functions.

    In addition, once we get past all the raw to useable argument, and you want to see how well the technology works, I suggest you download a copy. EMC has posted a full copy of the Virtual Storage Appliance and a VM.


    It's a full copy of the shipping Unified Storage code that you can try for yourself. No other storage vendor provides a full copy of their software, for free that anyone with a connection to the net can download and try.

    Want to really compare dedup technologies? Take some of your data on a filer and dedup it and measure the results. Then take that exact same data set (because we all know mileage varies) and then put that on your VSA file system and dedup that.

    How much savings to you get? Especially with VMs.

    Compression of a VMDK while it's running is a HUGE benefit – especially when you can turn that on from your VI interface. You can turn it on for the whole datastore, or just one VM if you like.

    How about that Challenge Nick? Put your code out there for everyone to try. Let's not battle this in the blogs – let's put real code in customers hands and let them take it for a drive! Where can I download my copy of OnTap? And would that be the old “classic” or the new Spin OS versions – I'm confused – and isn't that two operating systems.

    I guess we'll just have to agree that two components of software running on the same platform doesn't make the box bad – just different.

  • […] EMC 20% Unified Storage Guarantee !EXPOSED! | Christopher Kusek, Technology Evangelist – However since joining EMC, all I would ever hear from the competition is how ‘space inefficient’ we were and frankly, I’m glad to see the release of the EMC Capacity Calculator to let you decide for yourself where your efficiency goes. Recently we announced this whole "Unified Storage Guarantee" and to be honest with you, I couldn’t believe what I was hearing. So I decided to take the marketing hype, set it on fire and start drilling down into the details, because that’s the way I roll. […]

  • Before the excitement goes out of control – the secalc.com website is purely a marketing tool and the NetApp disk calculations when all the efficiency buttons are unchecked are incorrect (someone's oversight, we'll fix that pronto).

    Using the actual NetApp engineering capacity calculator, with RAID-DP (not single-parity) and spares, I need about 226 raw Base TB (or 200.9 base2 right-sized) to get 155TB base2 usable. Includes spares. No snap reserve. Which is just fine, at about 77% efficiency…

    All this excitement over nothing… oh well.


  • Mailbotx says:

    Netapp has two operating systems too, 7G and GX, but you can't run them both together (if I understand correctly). Have to agree with the other comments, what does this have to do with capacity of the arrays?

  • Dipesh says:

    On a personal note (as another former NetApp guy, this has been of particular interest), I would love to know how many actual pages of guidelines+guarantees (in total) stand behind the NetApp and EMC claims?

    On the NetApp site I found the FAQs (http://media.netapp.com/documents/virtualizatio…), the Technical Guide (http://media.netapp.com/documents/wp-7053.pdf), that also points to a number of other Technical Reports (for Dedupe Optimization, V-Series optimization, and then the VM-optimization based on which virtualization platform you're using).

    So counting that up, customer wanting to work within the framework of the guarantee would need to carefully read 15 pages (technical guarantee doc) + 46 pages on the dedupe optimization + 95 pages on VMware optimization + 20 pages on V-Series optimization. That's 176 pages, and I don't know if additional optimization reading/tuning would need to be done on thin-provisioning outside of what's in 176 pages, but let's assume it's all in there.

    Is there similar documentation standing behind EMC's guarantee, including guidelines? Providing more information on guidelines up-front is actually the right approach for the customer to make an informed decision. And it would be a more apples-to-apples comparison for prospective customers.

    Speaking of which: are there any customers out there who have already tried either approach / guarantee? Anyone willing to comment on their experience(s)?

  • Eugene says:

    Hi Chris,

    You and I have met a few times both in your prior role and in your current one. I respect the breadth of your experience, but this post feels somehow intellectually dishonest when viewed from a customer perspective.

    Dedupe has arrested our VM growth by 90% (easily 3/4 of all growth in our environment). Removing space-reservation from existing LUNs and volumes gave us back 40% of space that wasn't being used. We're going to start cloning for dev/test soon and reduce our footprint even further, and everything is thin-prov going forward. We mix and match protocols and tiers between different hosts and even on a single host through the same command-line and the same management concepts.

    In two years, we have not bought a single additional spindle even though from a host-side perspective, our environment has easily doubled.

    So while I have no doubt there are better raw capacity numbers out there (Seen Equallogic lately?), they just don't matter much to me as a customer (unless its cheeeeeeep!), if I'm drinking the Kool Aid properly.

    My guess is this post wasn't aimed at current NetApp customers, but I can't help but chime in with my real world non-consulting non-sales non-consulting-engineer experience.

    Of course, I haven't had a single experience with EMC kit, and would love to hear the same points as you raised from the perspective of a customer.


  • I'm glad you are able to rock your system out so extensively and intensively like you do. (Part of me feels responsible for some of the successes you've had in that success… but even if I'm not responsible, I'm glad you're having that success. :))

    This post was moreso an educational review of capacity utilization, while at the same time taking note of the “Unified Storage Guarantee” which reports that by switching to EMC Unified – Before you even start to enable features like thin provisioning, deduplication, etc – you will see a greater than 20% capacity savings.

    As to whether it was aimed at NetApp Customers or not – It didn't have a particular target market, however I wasn't going to exclude netapp customers, and I'll explain as best as I can in a real scenario which would happen numerously (very sadly numerously… but quite often)

    I'd walk into a customer environment on say a Monday morning. Customer says “Hey, we have our NetApp system on the floor! Let's start carving up space!” They were sold a 28TB Raw unit (in this scenario). They start to ask about “Hey, I bought 28TB I should be able to get to use 28TB right?!” And then, the most AWKWARD conversation {and respective whiteboarding conversation} commences. Myself (and so many others) were thrown under the Sales selling RAW v Useable bus, that we'd feel bad. Not for ourselves but for our customers, I mean I'm talking REALLY bad. [I'm thinking of a few customers in particular who were screaming and rather pissed off about this, not yelling at me per se – I don't like being yelled at] But I think you get the point. :)

    I can definitely find lots of other guys [customers] who have been in this same situation (was speaking with one earlier who expressed the same frustration) so it wasn't targeted at NetApp customers… frankly… more so on us frustrated engineers and architects ;)

    Although you do raise a good point Eugene – You should play around with some of the EMC kit :) You can download the Celerra Simulator if you want to play with that in your Lab or home workstation scenario – http://nickapedia.com/2010/05/19/besser-uber-ce

    And if you want I can reach out to the parties within arms reach and get them to show you what the 'Unified Storage' life is from the EMC side. – I'd aim for technical guys instead of those salesy guys because it's an educational journey, not a sales one. :) Let me know and I can get you the hook up :)

  • Nick Triantos says:


    Just because an argument is old, does not mean it is not relevant. By claiming it as “old”, you are really dating your architecture. :-)

    I find your disk tray analogy quite interesting but you might want to rethink it because regardless of whether you're dealing with physical disks, or are juggling balls in a circus fewer is always easier…

    If having a single management pane in order to manager *dissimilar* architectures is what unified storage means to you, it stands to reason that having a single way to replicate storage also makes a lot sense or having a single way to snapshot across different protocols or even having a single Site Recovery Adapter that works, natively, across arrays. At the end of the day, having a single replication strategy means there is also a single DR strategy for all storage regardless of protocol…

    A manager who wants an array that supports all protocols should not have to learn different tools to perform the same task, and should not have to understand different replication mechanisms to do DR.

    Compression/Dedup…Although both are space efficiency technologies, the method within in which these efficiencies are achieved are different and yield significantly different results. Let me explain:

    1) Deduplication

    Lets assume I have 10x 10GB identical vmdks. When you deduplicate you'll end up with 1 copy with 9 links pointing to it, resulting in 10GB of disk consumption

    2) Compression

    Again, I have 10x 10GB identical vmdks, when you compress, lets say you compress at a, absolute best case, 2:1 ratio (highly doubtful because compression works at the single file level and not across files), anyway, you'll end up with 10x 5GB vmdks resulting in 50GB required capacity NOT 10GB.

    Some vendors implement a combination of both. Do you know why? Because at larger block sizes, dedup yields very small returns, so it is passed to a compression engine, again, at individual file level.

    In case you haven't noticed, ONTAP 8 contains the foundational elements users need to build scalable virtual storage environments. Although our scale-out GX platform has been available for a while, we've really held off on pushing it until it was integrated with ONTAP and could leverage features such as SnapMirror, MultiStore, etc. In fact, as we’ve publicly communicated that 8.1 is where the rubber meets the road…what does your convergence roadmap look like?

  • Jonas,

    Thank you for your insightful perspective on this. I'm not sure there's much more I can contribute beyond that :)


  • Brad Elberman says:

    Chuck, Time to Quit. Your statements below to storage guarantees.

    “Personally, I detest marketing initiatives that prey on people's lack of familiarity with certain topics.”

    “Despite the fact that EMC abhors this sort of gimmick, I offered that for many years EMC has offered a storage optimization service where we come in and look at process and procedure with the goal of reclaiming underutilized storage. Sometimes we do this on the basis that we'll find more storage savings than the service costs, so you don't pay unless we find the pony.”

    ” If EMC were to do something similarly tacky, I'd probably quit in protest.”

    In other news, Paul Maritz, CEO of VMware, partially owned by EMC had not been reading Chuck's blog either because VMware last April also announced a guarantee program with Chuck publicly stating he “didn't particularly agree nor approve VMware's program but my opinion does not really matter because VMware operates as an independent company.” Fair enough.

    But now that EMC has put in a Guarantee program and Chuck's opinion DOES matter, he makes no statement on his blog….Looks like someone's in a hole…

  • Eugene says:


    Very good points all. I'm downloading the VSA now :)


  • John F. says:

    Unless the aggregate is used for sync snapmirror or metrocluster, the 5% aggregate reserve is routinely removed. Even if you keep it, it's typically 1-3% instead of the default 5%. Snap reserve is typically set to zero, and you provide space in the volume based on your change delta and retention. It's been years since it was 20%. The Clariion uses 10%. Can you or should you change that? At what change delta and snapshot retention is the Clariion assuming 10%? How much does Celerra add to that? But you knew that anyway…

    Hope things are going well in your new gig.

  • Indeed, I've always been a big fan of dropping the aggr reserve from 5% to about 3% (I've had friends with VERY specific workloads where they were comfortable going down to 1% or 0%) to tell you the truth though, that was a risk I was never really capable of taking, especially in situations where I have a fully populated aggr (an 8tb aggr where I can grow it, sure I can drop it more as I can always add disks… but in a full 16TB aggr… if I lose that buffer and hit an aggr full condition… support would spank me as well as local mgmt-side, it's painful and I've been through that enough to not want to repeat it)

    You can absolutely change what the default on the Celerra, just as you can change the default on the NetApp side of the house (I've seen so much space wasted/lost when people simply took the system at it's pure defaults not accounting for their specific workload or configuration – both positively and negatively when it came to snap reserves, not to mention when you reserve space but no snapshots are taken)

    Things are going well, Are you going to be at TechEd coming up in a few weeks? Always great to catch up with you! :)

  • […] all of the brouhaha and discussion from a recent post EMC 20% Unified Storage Guarantee !EXPOSED! I thought it valuable to dive a little deeper into our own […]

  • Any salesperson that sells raw (and there are a few at each company) should be summarily fired.

    The only thing that matters is usable space after all “taxes” have been taken out.

    Partners (for all storage vendors) complicate this since, especially the ones that specialize in multiple small transactions, pay very little attention to each deal.


  • Mike Riley says:

    In related stories:

    EMC has added beer taps to all arrays and renamed their firmware to “Information ONTAP” and their filesystem to Belgium Pancake.

    EMC has pre-announced that whatever NetApp's next guarantee or innovation is, people should immediately consider it “shenanigans” until such a time that EMC pre-announces that they themselves will launch a similar program. (On a side note: no one will inform Chuck – again. Seriously, Chuck, you should probably just focus on a follow-up blog for the iPad until this blows over.).

    EMC admits that their sub-lun level FAST v2 is a data-randomizing fragmentation engine that degrades system performance over time, apparently in an effort to pattern themselves after their mistaken belief on how WAFL really works.

    EMC Sales teams across the U.S. are required to enroll in training on how to say “Unified Storage” without making air quotes with their fingers.

    And, finally, Joe Tucci announced to his family that he is changing his name to Tom Menwarmenhitzen.

    Love the guarantee, guys, and the passion. Competition is good even if your NetApp spin is abouat as accurate as these other stories. If EMC guarantees 20% savings on their legacy arrays with a couple of bolt-on products – great! If you really want to bolt something on to those legacy arrays, try a NetApp V-Series. We'll guarantee 35% savings with EMC's own disk. You can add some NetApp storage to that config and we'll guarantee 50% savings on that. At the end of the day, customers can take a look at both approaches and make the call and we're more than willing to have that discussion now that you bring it up. We appreciate the additional attention on this topic of storage efficiency. Now, let's have at it in the market.

  • I absolutely agree Dimitris and I love your recent post/breakdown of a lot what goes in to those taxes (I read it after I posted this) but nonetheless, good stuff :)

    We should catch up over lunch some time! :)

  • […] You might remember me from such blog posts as: EMC 20% Unified Storage Guarantee !EXPOSED! and the informational EMC Unified Storage Capacity Calculator – The Tutorial! – Well, here […]

  • John4762 says:

    Check your 6, Chuck, check your 6!!! NetApp is the company that has been getting bigger in the rear view mirror. Seen the latest news from the Street??? Noticed how much market share you have lost in the Public Sector in the last 3 years? Having been a customer of both companies in the past, I would suggets that EMC has been asleep at the wheel while in your charge. If I owned any of your stock these days, I would be calling for your removal.

    Remember when it was NetApp that was “on the defensive”??? Wow! But hey, good luck with the marketing spin cycles and blog posts denying what the storage market deems obvious at this point… I wish you the best! :-)

    • Archives