« Mozy and Restore | Main | Overtake The Future »

March 31, 2009


Feed You can follow this conversation by subscribing to the comment feed for this post.


Scott, thank you for pointing this out. This is one of the most frequent traps that tends to distract us from the overall customer objective(s) - there's too much majoring on the minors!

Aaron E. Kristoff

Mr. Waterhouse, I must say that I really enjoy reading your blog and have for some time now (along with Chuck and S-zilla). It keeps those of us on the customer side of the storage/backup world interested on what is going on in the other side of the storage/backup world and I for one appreciate that.

I am however a bit disappointed in your reply to Mr Backup's recent blog series on the 3D4000 today. I had been anxiously waiting to read your 2 cents on his series and rather than challenge any of the arguments that were made you simply say "Some were right" and "they weren't relevant to the buying/ownership decisions for virtual tape and deduplication."

And then you put what matters. I simply see that as the vendor telling customers what matters so I use my filter when reading that. They are good points no doubt but atfer all was said, none of the arguments that Mr Backup brought up were addressed.

Scott Waterhouse


I appreciate the feedback and the candor.

I choose to respond to Curtis in the way I did because I sincerely believed we were losing sight of the forest for the trees. Now you can accept or reject, in whole or in part, my list of things which "matter". Or even better, you can add to it some of your own. Either way the piece was clearly an opinion piece--there was no attempt to say that this is what matters for you in particular, all the time, or any other user. Nor did I try to say that EMC products were better capable of addressing the needs of that list than some other vendor's products. Which would in my opinion overstep the bounds and become me attempting to tell you (in some authoritarian way) what is best for you.

As an aside, I would hope that you always use your filter when reading this or any other blog. Including Mr. Preston's. Because here is issue #2 with his presentation: he basically stacked the deck against EMC. He picks the criteria to exclude capabilities that he doesn't like. We can ingest at 2,200 MB/s, but he says that doesn't count. We can dedup at 800 MB/s, but he says that doesn't count. He says that you "need" global dedup but doesn't really justify why or attempt to quantify that. So my belief is he is telling you what matters too, and in a way that is no more (or less) honest than a vendor blog.

We all have bias, and any attempt by any of us (including Curtis) to deny it is just disengenuous in my opinion. His opinion may differ. That's fine. Curtis and I agree about 50% of the time at best!

Scott Waterhouse

Hrmph. Aaron, part 2 of my comment (typepad apparently didn't like the total length of my first reply!):

Having said all that, I will likely respond to Mr. Preston's specific comments in more detail. However, I think it is important for me to say that none of that response is intended to detract from my "what matters" statement. We can debate the details all we want, but there are still larger issues at stake. And I remain confident that even if you choose to categorically reject my list (because you don't want me telling you what matters) that you and most other technology buyers should buy not on the basis of how many MB/s a device is capable of, but of how well it meets your needs--needs that most likely bear at least a passing resemblance to what I laid out in "what matters".

Just my $0.02. Thanks for the response, and hopefully you will keep reading!

W. Curtis Preston


This is what happens when I go on vacation, huh? I missed these posts when they came out, so I'm finally responding to them now. Please forgive the delay.

First, I believe I _only_ talk about what matters to the end user. I dismiss arguments about inline vs post process, for example, as not being relevant. What's relevant is the ingest and dedupe speed. I dismiss arguments about hash collisions and explain why, as I believe it is nothing more than vendor FUD.

So why have I spent the time that I have on this subject? For a few reasons.

The first and most important reason that this all matters is cost. I know that in a later post you dismiss my cost argument. I'll set aside acquisition cost for now, as I know that EMC has been being extremely competitive in their street pricing. So let's talk about maintenance cost. Historically when I've seen vendors (including EMC) significantly discount the acquisition price, they do NOT discount the maintenance price. So the first reason that it matters that the 4000 requires more hardware than its competitors is that the maintenance price will undoubtedly be higher. The second cost element is power and cooling. If it does indeed require more disk and more CPUs than competing solutions, then it will cost more in power and cooling. And in the datacenters that I've been working, power and cooling is everything.

So my first reason that I spent all this time on the 4000 is that I do believe that an architecture that requires more components will cost more -- regardless of EMC's attempts to make that not so.

The second reason that I got so "nitpicky" in my posts is that you and Mark Twomey continued to assert that the architecture I described didn't exist. In a previous comment on this blog entry (http://tinyurl.com/cxhcnj), you said:

"There are not two boxes. Data may move between different pools of storage, but that is transparent to the application and end user. It is not one VTL sitting in front of another, it is one VTL period."

Well there are two boxes. And there is one VTL sitting in front of another. And I felt that it was important to say so.

And Mark Twomey said in a comment on my blog (http://tinyurl.com/czc4en):

"This idea of Front End/Back End you have is wrong. Like in other post processing architectures there is a native pool and a block pool." and "There is no cached copy." and "[data will] either be one place or the other. Never both at the same time."

Except there is a front end, and there is a cached copy, and data can reside on both the front end and the back end at the same time. And somebody had to stand up and say so.

Now that the truth is out there (and backed up by direct quotes from EMC's manual), you are saying that the architecture doesn't matter. You can no longer make the claims you were making (Curtis has no idea what he's talking about), so you're taking a different tack (Curtis argument is irrelevant).

So to summarize, I believe I have demonstrated that my description of the architecture is accurate and that this architecture is relevant, as it goes to cost of maintenance and cost of power and cooling.

W. Curtis Preston

I also wanted to reply separately to something you put in a comment:

"He picks the criteria to exclude capabilities that he doesn't like."

What else would you have me do? Who should pick the criteria, the vendors?

"We can ingest at 2,200 MB/s, but he says that doesn't count."

I say that ingest is only one number. If we're talking target dedupe, you better be able to dedupe it too.

"We can dedup at 800 MB/s, but he says that doesn't count."

No I don't. I said you can't dedupe at 800 MB/s. I say that you have two systems that know nothing of each other that can each dedupe at 400 MB/s. They are no more connected than two completely separate 3D3000s sitting out in the datacenter.

If you have 800 MB/s, then Data Domain has 6400 MB/s, as their DDX "array" is 16 DD690s in a box, each of which can do 400 MB/s. Those 16 arrays know as much about each other as your two 3D3000s.

"He says that you "need" global dedup but doesn't really justify why or attempt to quantify that."

Yes I do. I wrote a whole post on it:

"So my belief is he is telling you what matters too, and in a way that is no more (or less) honest than a vendor blog."

I'm not saying you're dishonest. I'm saying that you only see one side of the story and drink way too much of EMC's koolaid. I talk to customers of every vendor and see what matters to all of of them, and I'm not drinking any vendor's koolaid or taking any of their money.

The comments to this entry are closed.

Search The Backup Blog

  • Search