By Jim Haberkorn
We at HP like to test competitor arrays and see if we can match their published results. In our internal testing, only the NetApp results are so out of whack that we are left scratching our heads over what the heck they did to achieve them. So for NetApp, we have published our results and challenged them on it. And in fact, the NetApp folks at first put up a vigorous defense which included a fair number of attacks on the integrity of our engineer who did the testing, but then as the discussion progressed, the NetApp enthusiasts went quiet. See the blog post titled Making sense of WAFL.
So, we've argued against NetApp performance with numbers and the argument got very technical, and we won. But recently, NetApp, on one of its blogs, waited till the discussion had died down and then, to our surprise, acted as if they had won the discussion and that the issue now was totally resolved and that they had once again defeated the forces of evil. So, now NetApp has left us no choice but to try a new tactic: Logic.
The NetApp counter-arguments on the subject of their performance are becoming more and more like the man who admits it is raining, admits he is standing outside, admits he doesn't have an umbrella, but then denies he is getting wet. If you ask a NetApp engineer these performance related questions you will get the answer 'yes' to all of them.
- Do you build your LUNs on top of a file system?
- Does your file system write only to free block space rather than updating the old blocks?
- Do you ship a de-fragmentation tool on every NetApp filer?
- Do you use software RAID?
- Does your file system spread the metadata over the entire disk system?
- Does WAFL require you to build secondary inode trees if the file is bigger than 64KB?
- Can IOs to a particular file be serviced by only a single controller in a NetApp cluster?
- Do NetApp snaps reside in the same disk group as the primary volume?
- Is only a quarter of your NVRAM usable?
- Is the processing power of your largest filer, rated by NetApp to handle 1176 disks, based on a maximum 8 x 2.6 GHz AMD dual core Opteron processors - about the same processing power as a Proliant DL785?
- Is your file system optimized for writes?
But, if you then ask a NetApp blogger, if taken together, do these features negatively impact NetApp performance, you'll get an answer to the effect, "What are you crazy? How did you ever come up with that conclusion?"
Now, I am sure that every one of those eleven engineering decisions was made by NetApp for a logical reason from their perspective. But I am also sure that every one of them has a negative impact on NetApp performance, and the cumulative effect is pretty significant in most real-world environments. And those features put NetApp at a huge performance disadvantage in a storage world dominated by vendors who don't require the extra overhead of having to build LUNs on top of file systems, or don't need to ship a de-fragmentation tool with their array, or don't use software RAID.
Conclusion: Is every NetApp NAS customer unhappy with NetApp performance? Answer: No, of course not. But, of the storage arrays we've tested, is NetApp block performance the worst by a pretty wide margin? Yeah, looks that way to us.
Best regards,
Jim
Tweet this!
Posted
07-14-2009 4:31 PM
by
CalvinZ