I'm glad that you're an ex-Marine. What more can you tell us about yourself? Keep it upbeat; I'm not so keen on depressing life stories.

Pleasantries and introductions over, I'd like to add a little fuel to the fire.

You're a liar. For one, you don't have pointy ears. Two, you're illogical. Three, you keep mistaking anger for some other emotion (perhaps being in the Marines had something to do with that?). Four, this won't be your last post on the subject; logorrhea (or is it blogorrhea?) is a difficult disease to control.

On a less serious note, let's take the issues one more time.

Point 1 that you make;

WAFL is immaterial to the fact that in every 3rd party benchmark we've ever undertaken (SPC, TPC, ESRP, SpecSFS and probably others) demonstrate that it works; and works well.

WAFL deals in blocks. There's metadata that describes these blocks, and every SAN system I've ever come across has metadata. Does that make them filesystems? LeftHand has metadata. The EVA has metadata. LUNs are built on top of LeftHand and EVA filesystems if that's your point.

"At the protocol level, block-reads over NFS and block-reads over iSCSI are almost identical. The main difference is that NFS asks for a certain number of bytes, starting at a given byte offset, and iSCSI/FC asks for a certain number of blocks, starting at a given block offset. With NFS you must divide by 512 to convert bytes to blocks. So what! The other difference is that iSCSI and FC-SAN use a LUN to identify the container holding the blocks, and NFS uses a file handle. I’m over-simplifying, but you get the point. At the protocol level, for block traffic, there is almost no difference between NFS and iSCSI or SAN.

"A LUN and a file are both just containers that hold blocks of data, so get over it."

I'm quoting here from blogs.netapp.com/.../is-nfs-a-form-o.html. Worth a read. Then get over it.

Point 2;

Please run an industry benchmark on the FAS2050, and on the EVA4400. Then we can compare. And as John Martin (NetApp) has noted over on Karl's blog, HP asking for help in running IOmeter on NetApp kit is a little odd. We didn't ask EMC for help, and I'm sure their reply to us would have been a lot shorter and succinct than ours to you.

Point 3; I (for one) stand by the Mercer/Wyman report. You can criticize it as much as you like, but until you undertake a similar report... O hang on, you did, and even Calvin Zito disowned it.

"Last year, we commissioned an analyst team (The Edison Group) to measure the steps, clicks, and time it took to perform the most common array administrative tasks on several midrange arrays.  They wrote a paper about those findings called "TCO White Paper: EMC, NetApp, and HP Midrange Storage Arrays".  To be blunt, the paper never really measured TCO and in the end I thought it was the wrong title but it was still a good thing to see the time savings that we get with the EVA versus other arrays.

www.communities.hp.com/.../come-on-is-the-eva-really-that-easy-to-manage.aspx

And the paper in question is still out there on your website. Shocking.

I'm convinced that what you're doing here is making stuff up as you go along. I don't doubt you are less than impressed with the NetApp system you have, as you've made that abundantly clear. But the rest of your analysis, and 11 points, and terabyte sized spreadsheets, and peculiar psychology-driven emootional analysis are tangential to the issue.

NetApp works, and does so seamlessly across a range of use cases you just wish you could cover. Dream on, Jim.

Hi Jim,

I, for one, would never accuse you of hyper-sensitivity. Now hyperbole, on the other hand, is a different matter entirely!

Hi Alex,

Thanks for the additional proof points, but I thought I already had the issue of NetApp blogging tactics sufficiently covered.  

In any case, as far as WAFL is concerned, your LUNs fragment like a file, are slow, and act like a big file. Now, I really don’t care what you call WAFL. If you want to insist that it is not a file system then give it another name and start a marketing campaign to change the industry perception. If your arguments are widely accepted then the perception will change. If not, it won’t. But, whatever you decide to do, the first place to start is with the dozens of white papers on the NetApp website that all refer to WAFL as a file system.

But in the meantime, regardless of what you choose to call WAFL, it won’t change one bit the way it behaves in block environments.  And that is what we have been discussing.  

Best regards,

Jim  

Hi Lee,

And I would never accuse you of being verbose or bad tempered - only of betting on the wrong horse.

I'm still chuckling over your last post on Alex's Ibrix blog where you joked about HP buying NetApp. I'm picturing me, Alex, Kostadis, and Calvin in the same room having to make up.

Best regards,

Jim

Hi John Martin,

Okay, you got me. I realize I've been churlish in not even conceding a single point in all of these blogs. I will try to break myself of the habit of calling WAFL a file system. But, just tell me, if I get called as a material witness in the NetApp/Sun lawsuit - the one where NetApp is suing Sun over file system patent infringement - what do you want me to say?  

And also, please do me a favor in return: If WAFL should ever continue its evolution and eventually become self-aware, please do not – I repeat – do not try to shut it down. We all know how that story ends.

Best regards,

Jim

[Editor's note: Jim realized after writing this comment that he put it on the wrong post - this comment was intended to be on the "Why NetApp Gets Blogged" post]

Jim,

 fun as some of this repartee'  has been for me, I do most of it after hours and "She who must be obeyed" wants me to spend more time with her, so this will be my last post here for a while. Though out of courtesy I'll do my best to answer your questions.

1. I dont expect you to conceded any points, its not good debating technique unless by doing so you can progress  your own argument, and so far I havent seen too much progress, which is why this is all getting a little boring.

2. Are you likely to be called as a material witness in a patent infrigement case ? I didnt know you were either an expert in storage design or intellectual property law, either way, If you are sufficiently well informed about either subject I suppose  you follow the dictates of your concience, it's what I would do.

3. Who told you about WAFL becoming self aware, we havent announced that yet !

4. You clearly have some issues with Mercer's methodology for calculating usable capacity. If you're interested, look for a long series of posts from me on a proposed set of formal definitions and methodologies for calculating and comparing capacity and storage efficiency claims on the NetApp storage efficiency blog which will be coming out real soon now. I'd appreciate any challenge and feedback you, or any other reader of this blog might want to make.

Hi John,

Ah...an H. Rider Haggard fan. I just re-read 'She' a few years ago. But my favorite has always been 'Allan Quartermain' - the classic adventure book, way ahead of its time.

I said I would 'try' to break myself of the habit of calling WAFL a file system. But, yes, I did concede, but, you'll notice, only to you. Thanks for participating in this blog. I've appreciated your comments.

I normally don't read blogs unless someone points me to something, so when you do your post, why don't you drop Calvin Zito a twitter and he'll let me know.

And for the record, my issue with the Wyman/Mercer paper is not over usable capacity calculations, it's more fundamental than that. You should read my blog on the subject: www.communities.hp.com/.../netapp-apparently-still-lags-in-cost-of-ownership.aspx

Best regards,

Jim

I take your point about the word filesystem. Like LUN, it is commonly used to encompass things that are un-filesystem like. But as I saw a competitor claiming recently;

"...NetApp is NFS with a WAFL (random) file system."

That is clearly wrong, and the misunderstanding it typifies doesn't bear much inspection to reveal it for what it is; a ham-fisted attempt to obfuscate.

Customers demand, and the industry recognises that virtualsation is important to match the virtualisation capabilities that VM'ed servers already provide. This requires -- actually, stronger, demands -- that storage is divorced from the physical. We're already part way down that path; a LUN isn't a real device and hasn't been for many years. The word Logical in LUN kind of hints at that. And NAS isn't necessarily built on LUNs at all.

For block based, the next steps are away from tying LUNs to physical hardware, as VMs have done for physical servers. In fact, for all types of data, block or otherwise. Many in the storage industry are putting technology in place to accomplish this, and in the NetApp case, we have it now.

Even HP recognises this, with its purchase of LeftHand as you try to move forward from the old paradigm. With its block-based iSCSI over multiple nodes. To use your words;

"your LUNs fragment like a file, are slow, and act like a big file".

That I'm afraid is the future. What NetApp are doing is mitigating the "slow" bit, along with making sure with technologies like thin provisioning, snapshots and clones, along with dedupe that we mitigate the "fat" bit too, something that LUN based systems suffer from in spades. We've had 15 years of practical experience in doing this.

Your 11 points that you assert makes up a flawed technology would have some legs if you ignore all the other cool features that these 11 points and more enable us to provide in a NetApp system. What customers want is virtualised, flexible, reliable, space and performance efficent storage. They ask, we provide.

Finally, on a more personal note, your way of writing these pieces would appear to bring out the worst in people, as it has in me. Look at the number of negative comments you've had from NetApp people on this series of blog entries; they're as annoyed with you as I am. It's not a pretty sight, and it's not doing us any good.

Whatever. Guilty as charged, and I apologise for my attitude on your blog posts. I for one wish I'd kept my original promise to you not to engage you in "dialog". So I'm turning over a new leaf as of this reply; it's my last. Perhaps you could return me the favour.

Hi Alex,

It takes a big man to apologize. My respect for you has never been greater. For what it’s worth, I consider you a worthy adversary. Let me guess – you were in the Navy.

With that said:

1. In regards your point about my 11 points being cancelled out by your filer’s other good points. Yes, isn’t that how it always goes? – no product is a superset of all positive features in the industry. There are always design decisions that cause problems, but we live with them or try to work around them because they enable other positive features. What would we do without our engineers?  

2. Your Wyman/Mercer white paper. If you’ll remember, that is the paper that really started all this. It’s widely distributed. I just got another email last week from a sales team where it popped up at a customer. I’ve studied that paper. I’m possibly the only person outside of the author that has read every word and worked out the numbers, etc. I’m just going to say this: That paper has caused me to seriously question NetApp’s willingness to argue honestly in the marketplace. Sorry, that’s the truth. Myself I would rather have my competitors attack my products, technology, strategies, etc. But I don’t want them to be able to attack my credibility. But your paper arms me with the ability to do that to NetApp. And it’s that paper that keeps my antenna raised for ‘hidden tricks’ in other statements NetApp makes about itself.

3. Yes, I have received a lot of negative comments from NetApp bloggers. Sorry to say, I’ve seen those same types of responses on other blogs whenever anyone questions NetApp, so I never thought that I was provoking an unusually negative reaction.  

As far as returning you the favor: Well, it would help if you didn’t post my HP Confidential slides and refer to them as ‘nonsense’. So, I can’t promise that I won’t pop up on your blog, because that depends a lot on what you choose to say about HP. But I will say, that if I do pop up there will be no hard feelings. We’ll start out fresh.

The offer still stands: Dinner in Zurich on me if you should ever make it over.

All the best,

Jim        

Werent' Mercer asked, when presenting to a NetApp audience following their endorsement of NetApp in their whitepaper, who they used for their storage - to which they replied EMC?

Hi Big G,

Yes, I had heard that anecdote once myself, but have no way to verify. But the way these paid-for 3rd party endorsements work, if Mercer had been contracted by EMC the following week to write a COO study that favored EMC over NetApp they would've figured out a way to do it. And this is in no way a criticism of Mercer - it's just the nature of the business.  

Best regards,

Jim

Jim, a now-colleague was in the presentation so heard the exchange first hand. He said it was embarrassing for all concerned but, as you suggest, it's not really unexpected given the way these endorsements work. Still, you'd think both parties would have prepared for the potential question better.

Hi Big G,

Thanks for the back-story.

And like I've always said, anyone with any experience could come up with five legitimate ways to compare COO between competing arrays - without breaking a sweat. The fact that NetApp had to compare snapshots to full-copy clones to make it's case, along with its other shenanigans, does more to debunk NetApp COO claims than anything I could write.

It will be a sad day for the competition when NetApp finally takes that white paper off its website.

Best regards,

Jim