Comments on: NetApp’s messaging and users’ experiences

By: User response about NetApp and FC LUN snapshots — Storage Soup

User response about NetApp and FC LUN snapshots — Storage Soup — Wed, 19 Mar 2008 17:40:22 +0000

[...] Last week, I blogged about discussions I’ve recently had with NetApp and NetApp customers about the company’s messaging and products. One of the focal points of the debate was what users understood about best practices for overhead on FC LUN snapshots. A couple of users I’d talked to prior to reporting on NetApp’s analyst day event said NetApp best practices dictate at least 100% overhead on FC LUNs, but that NetApp salespeople tell them a different story before the sale. [...]

By: Delorean

Delorean — Tue, 18 Mar 2008 08:50:55 +0000

trying to forego the sales speak and just quote facts, we have a whole lot of shops running NetApp from SAN and 20ms+ latencys is not what we see at all! Both iSCSI and FCP run nicely and well within tolerance, yes there are less expensive SAN systems that might perform better - but they don’t manage/grow as nicely and don’t come with cool features - and we all know its about cool features!

(Cool being - NFS for VMware, CIFS to do without pesky file servers, iSCSI for remote DR site, clone features, etc.)

By: Sharles

Sharles — Fri, 14 Mar 2008 17:16:32 +0000

Who runs Netapp for block (SAN) anyway? Smart users know Netapp’s core competency is NAS and block is a nice (but inefficient) afterthought. The problem is, you can’t escape WAFL (which means you can’t escape their RAID DP unless you run G-series with a SAN array) and WAFL adds 20ms+ to your transaction. Even Clariion can do better than that.

Netapp needs to buy a real SAN vendor (like 3PAR) and stop trying to be a block play with their filers. Stick to NAS, devel a real Global Namespace or cluster product to compete with Isilson and forget about block. Either that, or figure out a way to let me turn off WAFL so I can save myself 20ms on my IO response time.