Chuck makes an interesting point below – the ability for an admin to choose where on a set of spindles his data will reside is a nice thing to have for the most demanding workloads. But these workloads are comparatively few. In fact, my personal experience with installed DMX and CLARiiON arrays bears out this one bit of real world experience –

If you are going to need dedicated IO's that the outer tracks of a set of spindles will give you, then *most likely* the workload is high enough that the inner tracks will go unused because you cannot afford to throw any other application workload at the spindles.

Hence the cost is very high – but sometimes you do run into this need. But as a rule, it is not needed for the vast majority of applications… just a very few.

Any other conversation is pure FUD. Been there.

I will probably blog on the Low Art of FUD soon. Why ?? Because the IT community needs to know this – FUD wastes *your* time and energy – not mine. All vendors have a database of some sort full of razor sharp answers to any and all FUD. Especially the kind that Chuck tosses around. Vendor Olympics is about the customer tiring himself out – not exercising the vendor.

We do this for a living folks!

Cheers !

Chuck makes an interesting point below – the ability for an admin to choose where on a set of spindles his data will reside is a nice thing to have for the most demanding workloads. But these workloads are comparatively few. In fact, my personal experience with installed DMX and CLARiiON arrays bears out this one bit of real world experience –

If you are going to need dedicated IO's that the outer tracks of a set of spindles will give you, then *most likely* the workload is high enough that the inner tracks will go unused because you cannot afford to throw any other application workload at the spindles.

Hence the cost is very high – but sometimes you do run into this need. But as a rule, it is not needed for the vast majority of applications… just a very few.

Any other conversation is pure FUD. Been there.

I will probably blog on the Low Art of FUD soon. Why ?? Because the IT community needs to know this – FUD wastes *your* time and energy – not mine. All vendors have a database of some sort full of razor sharp answers to any and all FUD. Especially the kind that Chuck tosses around. Vendor Olympics is about the customer tiring himself out – not exercising the vendor.

We do this for a living folks!

Cheers !

I'm Irish. I'll hate it forever.

Anyone else benchmarked the other guys tin yet?

I'll make sure we never support that piece of shit or that organisation.

As for translation layers and so on, not my issue on CX. At it's base the CX is cache and mathematical lookup. No file systems, not file systems or mutant duck/snake/spider animals. No worrying about where the metadata is or how it's protected or what happens if that metadata goes away. You give me the address you wrote the data to I'll perform a calculation then tell you the disk and sector the data is sitting on as well as point to the data integrity bits are right next to it.

Elegant, fast and not prone to bugs.

I certainly agree that this is important at all levels, but the discussion I linked to was totally focused on the specific case of the NX/AX and lower-end NetApp gear, at least to my eyes. If we open up discussion to the whole of enterprise storage, I bet the discussion would be similar, though the differences might indeed be greater.

Thanks for reading and posting!

If you don't mind, a few clarifying statements?

You are quite correct that most FC and iSCSI arrays compose physical disks and allow users to slice them up into logical chunks. However, this can be done preserving the physical nature of the drives, if desired — for example, putting data on outer tracks to get more performance, or laying things out sequentially if needed, or building certain kinds of wide stripes.

My issue with NetApp and similar emulated approaches is that you lose this capability. The array decides how to lay out the data, and not a skilled user. In some cases, this is not a big deal — especially when the workloads are not demanding. But, when workloads are demanding, you've taken away an important tool from the storage admin's bag of tricks. And this tends to show up in demanding FC environments.

Put differently, sometimes it's OK to have a file system abstraction layer between you and your disks, and sometimes it's not.

My second comment is that I disagree as to where this might be important. You state it's all about overselling low-end kit. I tend to think it's about having the right tools for the job at hand. Part of the problem is that statements like “Exchange ran OK” are meaningless without context, given the incredibly wide range of how people actually use these applications. I've seen people run Exchange inside a virtual machine from a desktop. It worked great — for what they were doing!

Finally, this argument extends well outside of the low-end, and into healthy-sized configurations of both NetApp's FAS products, as well as EMC's Celerra / CX product line, where perhaps the differences would be more noticeable.

Thanks again for a thoughtful post!

– Chuck

I've seen some really BLAZING performance from EMC's CX series, for example. And I've also seen it suck. It depends on how you configure it and what you are looking for!

I tend to be a realist. Whatever works (really works, not just sounds like it will) is always the best solution. And this is the point I was trying to make here: It doesn't really matter how unified you are or how emulated you are – it only matters if it's the right tool to get done what you need.