« Updates To The Capacity Post | Main | The Information Economy Continues To Grow »

September 03, 2008


Stuart Harrison

"EMC claimed the reason for such high reserves on block-oriented applications stemmed from the NetApp snap implementation: unlike other implementations, running out of snap reserve means your application crashes, rather than just having your snap job fail."

Or more correctly, if you run out of snap reserve for the volume in question, then additional space will be taken from the free space in the aggregate. The volume/system will not crash at that point.

This is however a unlikely event - either the snapshots are not being monitored and kept for an infinate period (without proper planning), or planning was not done properly initially.

If the customer requires X amount of 100% change snapshots, then X amount of 100% space should obviously be allocated. There are also various safety measures in place to ensure this is not exceeded.

Craig Simpson

My step back to look at the big picture uncovered some different thoughts from yours. You started this with a case where a chosen interpretation of best practices could make CX look better than EVA. Of course, if one levels the playing field by letting EMC configure the CX (like you did) and HP configure the EVA they both come out around 70% efficiency. I appreciate that you recognized some of our points. More is at: http://www.communities.hp.com/online/blogs/datastorage/archive/2008/08/29/emc-distortion-about-capacity-efficiency.aspx

However, since turnabout is fair play, I wondered if I could cook up a case to make EVA look lots better than CX. Sure enough. Put both a performance intensive workload (3000 IOPS, 1TB) and a non-performance intensive workload (300 IOPS, 1TB) on the array. The performance intensive workload uses RAID1 while the other uses RAID 5. Seems a reasonable mix of uses for an array. The EVA uses 30 disks compared to CX’s 41 making it 37% more efficient because CX can’t have RAID 1 and RAID 5 in the same RAID set. Now you could open the arguments about how your workload is better or I’m misusing your array or …

But the point is that anybody can find a way to make their array look good. Why did you use RAID5 for “Exchange” when you recommend RAID 1? Digging into the numbers shows it was important to making your array look good. If you really want to show a meaningful comparison let’s agree on a third party to define and do the comparison. Let’s make it a challenge. Loser pays and we both put it on our websites. I know we can get plenty of volunteers to run it. But if you don’t, then this was just a colorful marketing show proving anybody can make their array look good.

Val Bercovici

Hi Chuck,

The final numbers are in, and NetApp wins your contest with an efficiency score of 71%, whereas the REAL CLARiiON CX4 number is somewhere south of 50%, most likely 40-45%, as per your own ESRP submissions

Despite all the uncontested factual evidence provided by your slighted competitors here, as well the expert objective analyst opinions documented in the comments to your earlier related blogs, it’s not surprising that you will not concede the utter failure of your futile exercise.

To summarize:
• LUN’s on NetApp FAS arrays DO NOT run out of space. 4 years ago we had to recommend 100% space reservations to ensure that was the case, but for over 2 years now (with the release of DATA ONTAP 7.1.x) all customers have to do is simply enable our Snapshot AutoDelete (optionally coupled with FlexVol AutoGrow) policies to ensure that’s the case.
• Your premise that something dramatic happens when NetApp FAS arrays run out of LUN reservations is simply FALSE. As per the 2nd to last screenshot in my post last night, you can enable a default policy right at provisioning time to ensure this NEVER happens:
• It used to be that pictures spoke a thousand words. Does EMC need more to actually absorb a foreign concept?
• More specifically for MS Exchange 2007, I also reviewed our SnapManager for Exchange 5.0 Admin Guide in my initial response to you. That guide clearly spells out the various SAFE options in this regard, which again include ZERO reservations:
http://blogs.netapp.com/exposed/2008/09/emcs-storage-ca.html (see 2nd half of “The TURN”.
• No matter how much you wave your arms up and down arguing the nuances, RAID5 is not in the same league as the far superior RAID6 when it comes to disk resiliency. You’re off by 2-3 orders of magnitude.
• NetApp snapshots are NOT the exclusive forms of backup for Exchange customers – they are merely the FASTEST! As its name implies, our SnapVault technology automatically archives all snapshots to lower cost storage tiers. This is also configured by policy and remotely replicated via IP to any other (often deduplicated) NetApp FAS destination. Think Avamar – but natively integrated.
• As Curtis Preston also pointed out to you via his comment last night, your other premise that snapshots have equal value on all compared platforms is also patently FALSE. NetApp customers WANT more capacity reserved for snapshots, but can SAFELY turn those space reservations OFF if they value data capacity more than snapshot capacity.
• In your just published CLARiiON best-practices for Exchange, RAID1/0 is recommended and NOWHERE is RAID5 (8+1) even mentioned as an option.
• You also never address why that same paper discloses that your 146GB disks only offer 134GB formatted usable capacity. Where did that 9% go?
• Lastly, your ESRP submissions are all entirely based on RAID1/0 and also disclose the 9-10% loss of capacity due to formatting, so why are those EMC figures critical to your argument ignored?

I could go on, but for now to any objective reader it should be pretty clear that NetApp arrays are the safest, fastest AND most space-efficient SAN arrays for MS Exchange 2007, even by your contrived example.


Answering your CASE...
Make the 3000 IOPs as small as 146GB...
EMC will get a flash drive..
You will have to have get XX drives..
Good luck of getting a flash drive in your array!!

W. Curtis Preston


I'm going to come down pretty heavy in favor of NetApp here, so I want to throw out some disclaimers. First, I'm not being paid by them in any way, nor do I own any stock or anything of that nature. And it's also not my nature to post pro-NetApp stuff on an EMC blog. But the things you are saying about NetApp are so incorrect, and the inferences you are drawing from them even more so, that I feel I just have to respond. I'm on the side of truth here.

"Left unanswered was the question of why NetApp's documentation for Exchange was very clear in strongly recommending a 100% snap reserve"

This was answered several times. It's because that's how people use NetApps. It's not because of what you say (the danger factor).

"Or why this was the apparent default on customer systems."

It's because that's how people use NetApps.

"EMC claimed the reason for such high reserves on block-oriented applications stemmed from the NetApp snap implementation: unlike other implementations, running out of snap reserve means your application crashes, rather than just having your snap job fail."

No it doesn't. Read Val's latest post. If you run out of snap reserve, the filer will take space from your primary volue. If taking space from your primary volume still isn't enough, they'll automatically delete the oldest snapshot for you to make room. Voila. The problem you're trying to point out doesn't exist.

"It was also clear that any changes made to the NetApp-recommended defaults were largely at the customers' own risk."

And customer changes that are made to CX arrays that differ from the docs and weren't done by contacting support or using EMC consultants AREN'T at the customer's risk? Again I say that having a 0% snapreserve is documented in the manual referenced by Val.

"As a result -- for now -- we're sticking by our original storage capacity efficiency comparison for NetApp FAS in block-mode environments such as Exchange -- until such time as NetApp publishes different recommendations."

Which they have already. Val said that the recommendations you are looking for are already spelled out in the SnapManager for Exchange manual. Have you changed your comparison yet?

"Some questioned the "fairness" of comparing RAID 5 (used by CX and EVA) with FAS's RAID 6. ... Let's just say that there are valid points on both sides, shall we?"

Um, no. I have seen no valid points on your side that shows that RAID 5 with a hot spare in any way compares to RAID 6, regardless of vendor, and I don't care if we're talking 1 GB disks. So I will not say that there are valid points on both sides.

Since it's beyond the scope of this post, why don't you post a blog title of "RAID 5 is as good as RAID 6." I'm sure Scott Waterhouse would love to chime in, as he's currently really slamming NetApp because their VTL doesn't use RAID 6. Hilarious that at the same time you're arguing that RAID 5 with a hot spare is just as good.

"One interesting thread that was uncovered in all of this was the proper use of snaps:"

The fact that it seemed to come as news to you how people use snapshots on a NetApp, and that you seem to STILL not understand how people use snapshots on a NetApp is proof of the fact that you shouldn't be posting comparisons at this level of detail. You can't compare technologies you don't understand.

"At EMC, we've never really thought of them as true backups. Sure, you can use a snap or clone to expedite the making of a backup, but it wasn't the backup itself."

Of course you don't think of snapshots that way. Keep 30 days of hourly and daily snapshots on a Clarion and watch what happens to its performance. I don't think you'll like what you see.

As to it being a "backup itself," it absolutely can be a backup -- for the purpose of restoring from logical corruption. Logical corruption (deleted file, deleted mailbox, etc) is the number one reason for restores -- especially given that everything is on RAID these days. Delete a mailbox or file? Wouldn't it be nice if you could just mount a snapshot from before you deleted it, and drag the mailbox/file back where it belongs? (That is instead of having to actually copy/restore that data all the way from some other device.) When you've got days, weeks, and months of snapshots available to you to do instance restores, it's amazing the uses you come up with.

Five years ago, I watched a customer be forced by upper management to move their Oracle databases off their EMC frames and onto NetApps. (Acquiring company was an all-NetApp shop.) They were FUMING. How could this filer crap be as good as our high-end EMC stuff?

Well, once they got a taste of snapshots and snaprestores, they stopped grumbling and never looked back. They discovered things like taking a snapshot before an Oracle upgrade and being able to instantly go back if they didn't like what they saw -- and being able to leave that there as long as they needed without any performance impact.

"I learned in this process that -- yes -- there are snap-happy vendors who seem to be proffering this as a substitute for a safe copy of your data sitting on a separate physical device."

No one ever said that so I don't know how you learned it. No NetApp sales rep or SE would ever say that, and certainly no documentation would ever say that. Besides the fact that it's a stupid thing to say, it goes against them wanting to sell snapmirror/snapvault and another filer.


Hi Chuck,

I work for a storage vendor - but I do not want to wave their flag here or argue with you. Obviously you are EMC, and you will create a scenario where you win, and NetApp and HP will create similarly slanted winning scenarios. I am sure also, those vendors we have left out of this argument will tell customers that their mid-teir array is the safest, fastest and most space-efficient storage array.

I just wanted to take the time to give you kudos for allowing all comments on your blog. As a moderated blog, you could play any game you wanted, even have EMC staffers pretending to be customers to give you credibility.

Keep us thinking Chuck! Thanks.

Calvin Zito

Hey Chuck,

I appreciate the admission that you configured too many disk groups for the EVA. However, I'm a bit surprised that you then went on to make recommendations to HP StorageWorks customers on how they should configure an EVA. Given you really don't understand the EVA (as you've already demonstrated) I think it would be best if you stuck to making recommendations on how to optimize CX capacity for EMC customers. Until you have an EVA test lab and an EVA services practice that can match what HP offers, your advice to EVA customers isn't credible.

By the way, the challenge that Craig Simpson offered still stands - we'd be more than happy to get a third party to determine which array is more capacity efficient. I'm not suggesting we include Network Appliance's FAS array - we've already had a third party survey customers and we learned that the EVA had 34% better capacity utilization over a FAS. We'd love to do a third party comparison with the CX and as Craig said, losers pays and we both post the results on our website.

Thanks for drawing attention to the topic!

Chuck Hollis

Hi Curtis -- yes, you're coming down heavily in favor of NetApp, but as I read your response, I have to admit it doesn't have your usual dispassionate tone.

First, I apologize to you and Val. I missed the bit about deleting old snaps. If that's the case, then I stand corrected.

I believe that Val and NetApp have some correcting to do as well in their basic Exchange docs (as opposed to the SnapManager docs) since that's where EMC (and customers!) get their information.

I am well aware on how people use snaps.

Please don't forget, TimeFinder was introduced by EMC back in 1995, I believe. I spent a good deal of my time on EMC educating people on the benefits of seperate copy of, say, an Oracle database long before NetApp came into the picture.

Frankly, I'm a bit surprised that you would equate a copy of the data on the same array as offering equivalent protection as a copy of the same data on a separate physical device.

Regarding your belief that RAID 6 is "better" in all cases (and all disk sizes!) than RAID 5 with proactive hot spares, there is much we need to discuss, dear sir, including a cost-benefit calculation.

As far as slow, I'd invite you to fill up a NetApp FAS array to 90% of its logical capacity, and then run any write-intensive benchmark on it.

It appears that NetApp arrays can be fast, or full, but not both the same time.

Let's cut to the real chase, shall we?

Here's what we consistently see -- every time we go see a NetApp customer, and they let us check their storage capacity and efficiency, it's usually abysmal.

As in "really, really bad".

Between losses associated around disk right-sizing, "free" reserve for WAFL, and plenty of space left for snap reserves, extra spindles to solve performance issues, etc. it's usually a pretty poor picture.

That "free" capacity isn't free: customers pay for the hardware, the maintenance, the power and cooling as well as software associated with it.

Especially in larger shops, when we show them the real numbers, jaws drop. And we usually end up selling them a more efficient environment, and paying for most of it out of the cost savings.

Regardless of how NetApp might be able to "theoretically" run at certain efficiency levels, the results in actual customers' hands seem to be far, far worse.

Some of those customer comments appear on this blog, by the way. They're not unique.

Listening to you (and Val), it seems to be all for the good. Rather than take my word for it, I'd encourage you to speak to larger NetApp customers about this particular efficiency issue.

If, after visiting with the management of these larger shops, and you believe that we're incorrect in our views, please let us know.

Thanks for writing!

Chuck Hollis

Hi Craig

Your points about the potential of picking use cases to make one array look good or bad are well noted.

As far as your example, you didn't supply enough detail to allow me to judge whether your conclusions are correct or not.

One key difference between CX and EVA seems to be in the approach to hot spares: ours are global (hence more efficient), EVA's seem to be directly associated with the disk group, and must be sized logically (e.g. large) rather than physically.

Thanks for writing

Chuck Hollis

Ahmed has a valid point.

We're finding wonderful performance results by simply relocating a very small portion of larger applications to enterprise flash drives.

Even as little as 4-8% of an application -- properly relocated to a small slice of an enterprise flash drive -- can boost application level performance by 40-200%, depending on the situation.

The real winner here that we're seeing is when customer are running multiple applications on an array, we put in a small amount of enterprise flash, slice it up, and hand out small bits to the hot spots of all the applications.

I think the spindle-randomizing array vendors may have a challenge pulling the same trick.

Chuck Hollis

Hi Val

Now, you and I both know that published best practices for Exchange and ESRP submissions are two different things. At least, I think you should know this.

As I mentioned in a previous comment, would you care to offer a reasonable explanation why we meet so many larger NetApp shops with such abysmally poor effective utilization (raw vs. effective)?

If your customers were actually GETTING 70%, rather than south of 40%, we wouldn't be having this discussion, would we?

Oh, BTW, suggest you go update your Exchange best practices docs to reflect the new advice. Customers must still be using the old ones ...


Chuck Hollis

Hi Calvin -- and Craig

You know, I believe that if we were to do one of those surveys, we'd probably find that the CX and the EVA would probably be in roughly the same league in terms of storage capacity efficiency.

I think you'd have a minor disadvantage in two areas: how you protect individual disk groups, and the need to leave sufficient free space for the EVA to reorganize things.

But we're quibbling.

Compared to NetApp FAS and others who don't think efficiency is all that important, we're actually on the same team, so to speak.

As a case in point, consider IBM's XIV (and Pillar, I think) who are arguing the case that throwing tons of cheap ATA drives in RAID 10 configurations is the "answer".

Compared to this crowd, we both look like saints.

Val Bercovici


I gotta hand it to you - you're a trooper. Curtis has laid bare the fallacy of your position here, yet you keep hammering away at your marketing points like Sarah Palin did dutifully last night.

Sales legends exist on both sides, so I don’t doubt you may have stumbled upon disgruntled admins somewhere in an enterprise who did not agree with a NetApp decision, much like we encounter dissatisfied EMC customers on a regular basis as well. This is the heart & soul of a strong competitive market which ultimately benefits all consumers!

Just to remove any potential ambiguity here, NetApp *does* think efficiency is vitally important. In fact our overall value proposition and effective marketshare gains since our inception are largely based on it!

And there is NO debate in the storage industry (outside this blog apparently) that RAID6 has vastly superior disk group protection characteristics compared to RAID5. The only debate is who has proven their RAID6 implementation can perform at very high levels.

EMC and NetApp have vastly different views on storage efficiency and logical vs. physical data availability, as evidenced here on your blog. Let's just say NetApp looks beyond the LUN's or files at how the data can be abstracted and virtually cloned (for protection, virtualization, testing or other business uses) many, many times. EMC has a more tangible 1:1 approach to clones. Much like the contrasting levels of protection between RAID5 & 6 yield orders of magnitude differences in disk group resiliency; virtual, thin clones (i.e. NetApp FlexClones, based on our highly differentiated snapshot technology) also provide orders of magnitude more usable capacity. FlexClones have the same usability and performance profile as physical clones which in turn chew up much more capacity resulting in lower overall efficiency. This is, after all, the NetApp game changer, not a periphery in our portfolio.

Also, anybody can concoct an edge-case workload to make an array look bad (small-block random I/O on DMX anyone?), but FWIW - we published a specific SPC-1 benchmark showing consistently high performance over a 4 week period. I shared it with Chad the other day over here:

Finally as "Anonymous" said above, kudos for not filtering inconvenient comments on this thread!

Paul Hargreaves

Chuck> Now, you and I both know that published best practices for Exchange and ESRP submissions are two different things. At least, I think you should know this.

The main purpose of ESRP is to give customers proven best practice completed solutions:

Just search for "best practice" on that page... mentioned several times.

Are you saying that EMC do not follow best practice when performing their ESRP submissions?

Chuck Hollis

Hi Paul

No, of course not.

But you knew that, didn't you?

ESRP is defined by Microsoft -- they have a lot to say about how they'd like to see things done, whether or not we agree with them or not.

I think the key point you're missing here is that every vendor gets to decide what they think best practices might be.

Imagine running Exchange on ESX on an HP server on EMC storage. You'd have the benefit of at least FOUR best practices: one from Microsoft, one from VMware, one from HP, and one from EMC.

To sit back and say "hey, these are all subtly different" is a bit naive, in my opinion.

Chuck Hollis

Hi Val

A "few disgruntled sysadmins?".

The longer you folks stay in denial the better.

Here's the problem it's not enought to stand back and claim what's possible, your company is accountable to make sure that customers actually get the results ... right?

As long as we're debating philisophical differences, let's highlight a few that you shared.


NetApp's position is that it's superior in all use cases, regardless of cost or impact.

EMC's position is that it's an important option that sometimes makes sense, and sometimes doesn't. We like RAID 6 for some applications, RAID 1 for others, RAID 5 for still others, and certain other schemes (e.g. Centera's approach) for other use cases.

Storage efficiency:

NetApp's position is that storage inefficiency is more than outweighed by the potential functionality of the environment.

EMC's position is that customers should have a choice as to whether to optimze for functionality or efficiency. The difference with our features? You can turn most of them off if you'd like. No such flexibility from NetApp: WAFL is WAFL.

Storage architectures:

NetApp's position is that a single architecture and operating system should be more than enough to serve the storage needs of the marketplace.

EMC's position is that no one array architecture can meet all needs (including random small-block I/Os), so we have different product families, giving customers a choice.

I see a recurring theme here, don't you?

EMC: let's understand what you're trying to get done, and propose the best solution.

NetApp: there's only one way to do things, period.

BTW, you and the other NetApp bloggers might want to consider writing about something other than EMC and my blog from time to time.

You're making people think you guys are obsessed or something ... :-)

Val Bercovici


I’ll try and end this now tiresome circular debate as I began it – with the simple statement that most customers NetApp engages with are usually interested in their own custom balance of:

1. Availability,
2. Performance,
3. Efficiency, and
4. Overall Cost.

NetApp’s focus and proven track record is on all 4, not merely one or two of the above. NetApp’s published best practices (with the few notable outdated exceptions you have highlighted) match our authoritative, transparent, independent benchmarks and studies to validate our position on all four.

Objective industry experts and NetApp customers plus partners have weighed in here and elsewhere in the storage blogosphere en masse against your inflammatory claims backed by nothing more than EMC salesforce anecdotes and internal studies which contradict everyone’s best-practices (HP’s, EMC’s, NetApp’s and Microsoft’s).

I’ll leave it to your readership and mine to determine what legitimacy EMC has left when making claims against NetApp.

Finally, much like the political campaigns of 2008 have learned from the past that “staying above the fray” does not always succeed – you can be sure NetApp bloggers will now actively engage EMC’s inflammatory bloggers anytime, anywhere and finish those fights you choose to start.

If you want peace, save what credibility you have left and blog about EMC. Leave the competitive claims to the objective voices of independent experts and customers.

Chuck Hollis

Val --

My, aren't we feeling full of ourselves today?

Have a nice day ...

Martin G

Let me say as a customer of both of yours, both your sales-forces (EMC and NetApp) are equally guilty of dissing each other and getting the capabilities of each other's products completely and utterly wrong. And I always take what a vendor says about a competitor's product with a huge pinch of salt!

You can often learn a lot about the weaknesses of a product by looking at the areas of the opposition's product that the sales-person in front of you chooses to trash, often a case of classic indirection!

Now, I know some customers get taken in but fortunately for me, I've worked pre-sales so I know the game!

Anyway, Chuck...can you find another hornet's nest to stir up now? You appear to have got everyone's attention now!



Another paradox in your argument...?
"EMC's position is that no one array architecture can meet all needs (including random small-block I/Os), so we have different product families, giving customers a choice."

So where does that leave http://chucksblog.typepad.com/chucks_blog/2008/08/emc-unified-sto.html?

I gotta tell ya, I'm lost. Bet customers are as well now. Is that what you tried to achieve?

Chuck Hollis

I'm getting tired of playing footsie with NetApp guys who have nothing better to do with their days than leave non-sequiters on my blog.

If you really don't understand the difference, I'll explain it to you. But the rock-fetching exercise is getting tiresome.


Chuck Hollis

Martin, thanks so much for contributing your perspective here.

Stirring up hornet's nests is what I seem to do from time to time.

And -- hopefully -- it's always an interesting discussion.

W. Curtis Preston

You are correct. My response was missing my usual dispassionate tone. That's because I had become passionate. I felt that the claims you were making (things like "NetApp customers MUST use 100% snap reserve" and comments about "snap-happy vendors") were clearly unfair and unfounded based on both documentation and best practice as defined by people who actually understand NetApps. I feel better now. ;)

I never equated array-resident snapshots as equivalent to a copy somewhere else. I merely said having them -- in addition to those other copies -- on the same array is a very nice thing indeed. If you don't also have some other copy, well, you're a moron and you deserve to lose your data and your job. (I feel the same way about someone whose only copy is a BCV in the same frame as the production data. It's slightly better, but a few flames will change that.)

I'm going to have to call you on your history again. 1995 is not "long before NetApp came into the picture." They were founded in 1992. At the time EMC dismissed them and the whole NAS concept, so I can see how you would think that they weren't in the picture. But they definitely were.

As to your anecdotal sales stories, I'll step aside. I will say that NetApp has built a nice little business, and ALL their customers can't be unhappy.

You're absolutely right. They have a "one size fits most" approach, and that approach doesn't please everyone. (I say "most" because there are configs and requirements that even the best NetApp box and/or sales rep can't meet.) But for those it does please, it does come with a much more tightly-integrated story than any other vendor in the industry. You can use snapshots, snapmirror, and snapvault on any product in their product line, whether you're doing user-level files, NFS-serving of Oracle data files, or block-level Exchange data. The EMC flexibility that you're touting has tremendous value to those that want that flexibility. But it also comes with complexity, with different snapshot, replication, and management products for DMX, CX, Celerra (NAS), and Centera (CAS). Those who want more flexibility will be drawn to your product line, and those who want simplicity will be drawn to theirs.

Chuck Hollis

Hi Curtis

The only reason I'm correcting you here is that I know you pride yourself on accuracy.

The introduction of TimeFinder was the first array-based local copying function in the marketplace. I believe it predated NetApp's introduction of snaps by about 3 or 4 years.

Another correction: many of NetApp's features were designed for NAS environments. When one looks at their block-mode emulations (iSCSI and FC), certain limitations emerge -- it's not as pretty a picture.

EMC sells a simplified unified storage device (Celerra) that has the many of the same use cases (and similar functionality) as NetApp FAS.

For the parts of the market that prefer this simplifed and unified model, we have a product that does this.

Roughly speaking, the Celerra product family spans much of the same range of the FAS family, although one could argue that certain aspects of the high-end NSX exceed NetApp's products.

That would make the remainder of the EMC storage product family a superset in terms of functionality and architecture.

As an example, NetApp currently offers no object addressable storage (CAS), no native midtier FC array (CX), and certainly no enterprise-class high end array (DMX).

Nor do the offer path management, backup applications, and a reasonable list of other storage-related functionality.

As you point out, many customer use cases cannot be served by a simplistic NAS head trying to emulate block protocols, no matter how clever.

Hence different members of the EMC product family.

What irks me is that we often see NetApp either try to pretend that customers don't need this sort of thing, or (worse) that their products can actually support these use cases, which ends up hurting customers.

Where they fit, they fit well. And where they don't fit, we often see a very ugly picture indeed. One of my pet peeves is that they don't stick to what they're good at, and we see a lot of collateral damage as a result.

I shudder to think what might happen if someone would try to run a serious DMX workload on something like a NetApp FAS. I hope someone has a fire extinguisher around .. :-)

I'm glad you think that NetApp has a cool product. Actually, I think many of their features are pretty cool as well.

But I draw a line between saying "cool feature" and trying to solve a majority of customer challenges with a single architecture.

I see that you're starting to take an interest in storage-related issues beyond your normal backup-related discussions.

If you're serious about this, we'd be glad to spend some time sharing with you what the portions of the storage market left uncovered and underserved by something like a NetApp FAS might look like.

Best regards ...

Chuck Hollis

Val -- I'm not going to post your most recent comment here.

I've decide to put you in "time out" for unprofessional behavior.

I think I've been more than accomodating in tolerating your insults and unpleasant tone. Everyone has their limits, and you've reached mine.

Want to rant unprofessionally? Go do it on your own blog, please, not mine. I'm done with you for the time being.

Val, I'll let you out of your room when you promise to behave more like a professional, and less like a child.

Now, go think about what I've said.

-- Chuck

Dave Mcdonald


Your comment to Val was beneath a corporation of EMC's stature, as well as beneath an interchange of ideas between two industry execs.

The only question remains - is it beneath you?

I urge you to apologize to Val and publish his comment for all to see and judge.

By mistreating him like a child, you insult as all in the same manner.

Chuck Hollis


Val and a few of his colleagues have decided to veer into a mode of continual personal attacks against me.

Please don't get me wrong, I'm all about a healthy debate about products, strategies, etc. Ditto for the company I work for.

But most people would draw the line when it becomes insulting, demeaning, etc. on a personal level.

That's just not called for. As a matter of fact, we'd probably shut down any EMC blogger who took that approach.

I don't think it's beneath any individual (or company) to expect a certain level of respect and courtesy from others when debating issues.

Like I've said before, it's OK to disagree, it's not OK to be disgreeable.

Since Val and his colleagues don't seem to know where that line is, unfortunately I have point it out to them.

And, as a result, I've decided not to post a few of the more choice comments that they've left on this blog.

If Val and a few others are willing to maintain a certain degree of civility, I'd be more than pleased to entertain their comments here.

Since it's my blog, I get to set the standards of conduct here. Feel free to disagree if you'd like.

Just don't be disagreeable, ok?


Ken Steinhardt

Having worked in this industry for vendors (two of them) but also more importantly as a customer in IT prior to that (it was called "Data Processing", and then "MIS" in those days...), I have come to a hypothesis that some others have attributed to me by name, since I've tended to share it so often over the years - and it goes like this:

Steinhardt's Theory of Customer Beliefs: In their never-ending attempt to get to the truth, customers tend to have a very specific hierarchy of beliefs that they will weigh in order to arrive at their own personal perception of truth, and in priority order that hierarchy is 1) Their own personal hard experience, 2) The experience of other customers, 3) The opinions of third-party sources (academics, journalists, analysts), and 4) Vendors.

In this elongated discussion, there have been pieces from all four represented - some much more than others. I believe that Chuck has done all a positive service by raising the significance of evaluating the issue of capacity utilization, particularly in exposing the fact (can we agree that this is a fact?) that reality is not always what appears on the surface. I encourage all customers that have been following this to look to your own experience and the experiences of others that you respect to verify the reality of the basic issues that Chuck has raised in this discussion, and I suspect that you will probably find truth.


Steve Marsden


I've read all the blog entries and comments and it does seem that a hornets nest has indeed been opened. I think open debate is important so thanks for being game enough to raise an interesting topic - and for taking the flack that it produced.

However, not one to be swayed by Vendor kool-aid, I really wanted to do my own research and I have to say, I'm not surprised there is a level of confusion here.

Firstly, while the EMC Best Practice on Exchange does say that RAID 5 and RAID 10 are acceptable - it also implies a 4+1 implementation. However, it doesn't rule out 8+1 so I guess that's fair.

What is more surprising is how Val can state that 100% Fractional Space Reservation is not a recommendation from NetApp. I agree with you - I can't find a single "Customer Facing" document from NetApp that concurs with his point of view. In fact, if you look at their own ESRP Documentation,


the Total Formatted Capacity on page 10 would validate your findings.

HP also think that there is something fishy with using NetApp for Block I/O.


Despite the heat you have taken, I think the weight of evidence is in your favour on this point and if Val truly believes that Fractional Space Reservation isn't required then NetApp Best Practice documents should reflect this - otherwise Val's comments lack any level of credibility.

Thanks for the blog.

Phil Wild

I am a year behind this discussion but found the debate very interesting. I am an EMC customer and we are about to go to market for an additional 200TB of storage.

I must say that I find your arguments about RAID5 vs RAID6 and snapshots for backups very interesting. I am sorry but the continual arguing and obvious lack of response to certain points raised by your competition and other interested parties has given me good reason to consider product other than just EMC.

Like others have said though, kudos for bravely publishing all comments.

Kind regards

Chuck Hollis

Hi Phil

So much has changed in the industry since we had this debate that I wouldn't base an informed decision on what you see here. I leave it up for historical purposes, not as a source of current and/or accurate information.

You should always consider all alternatives -- that's great. But, in this case, you might want to refresh yourself on the current state of technology and the associated tradeoffs.


The comments to this entry are closed.

Chuck Hollis

  • Chuck Hollis
    SVP, Oracle Converged Infrastructure Systems

    Chuck now works for Oracle, and is now deeply embroiled in IT infrastructure.

    Previously, he was with VMware for 2 years, and EMC for 18 years before that, most of them great.

    He enjoys speaking to customer and industry audiences about a variety of technology topics, and -- of course -- enjoys blogging.

    Chuck lives in Vero Beach, FL with his wife and four dogs when he's not traveling. In his spare time, Chuck is working on his second career as an aging rock musician.

    Warning: do not ever buy him a drink when there is a piano nearby.

    Note: these are my personal views, and aren't reviewed or approved by my employer.
Enter your Email:
Preview | Powered by FeedBlitz

General Housekeeping

  • Frequency of Updates
    I try and write something new 1-2 times per week; less if I'm travelling, more if I'm in the office. Hopefully you'll find the frequency about right!
  • Comments and Feedback
    All courteous comments welcome. TypePad occasionally puts comments into the spam folder, but I'll fish them out. Thanks!