Carter – I really take issue with anyone saying CORE is flawed. The Wikibon guys took me through it as well and I actually happen to know David Floyer, their CTO, very well. His logic is on target. Remember – the ultimate value of CORE – Capacity Optimization Ratio EFFECTIVENESS is in the “E” for customers.

I agree with your last sentence – “Don’t you have to at least do something useful before it matters how fast you do it?” The answer – of course, but you only pay for products that add value. Some people are complaining online that if you just get 1% compression and it happens really fast, then the CORE number is unreasonably high. But I would argue that it SHOULD be a high CORE number because it is “E”ffective for Customers. Now, will they pay extra for it? Not likely, but they will use it. A good example would be extra performance on a Nehalem. If it helps, the Customer uses it, but will he pay an extra adder from another vendor for that 1%? Not likely. In this case the “C”ost of the solution would be zero, and the CORE number would thus be infinity. The point is that if you add something that adds “E”ffectiveness, and if it does not cost anything from a CPU or memory resource aspect of the system as it is currently designed, that is the optimal solution. Period.

EVERY answer in IT is ‘It Depends’. Is doing compression in ‘real-time’ with no impact to performance (fast), applications or deduplication for backups, more or less “E”ffective than post process deduplication? Ask this question to 100 customers. See what the answer is – I’ll even help sponsor a survey with you guys, done independently, to see what they would say. Time to compress is highly critical IF you are going to do ‘real-time’ data compression.

I am sure there are a number of instances and use cases that fall out-side the real-time, random access compression needs that are a huge fit for Ocarina, NTAP, EMC, etc… but if you want to do compression, in real-time, in an enterprise environment, in front of a customers active solution, you need to be very fast, agree? Customers buy storage for two reasons, performance and availability. Any vendor who thinks they can sit in front of that needs to preserve these characteristics. This is ultimately what CORE shows, Storwize does not impact end user performance.

The Wikibon CORE is based on research – not a ‘vendor’ trying to ‘fool’ customers. I also agree that time to decompress is also important. I would say end users would see compress and decompress (read / write) as equal however. Again, CORE and the effectiveness is important when looking at adding value throughout the entire data life cycle. Example, if I use Ocarina deduplication, but have already purchased Data Domain, don’t I need to re-hydrate the Ocarina deduplicated, primary storage data before I use Data Domain? They say you do. That means I don’t really save on my primary storage if I need the space to re-hydrate before I back it up and that also means processing time on the array. Storwize, with random access compression doesn’t require decompression. (See the white paper on the web site, Storwize improves data deduplication.)

Lets just be honest about a Product’s capabilities and allow the Product to prove itself within a customers environment, including things like ‘Does the customer need to change the application?’ ‘Does the solution integrate with deduplication?’ ‘Does the solution impact storage performance?” At the end of the day there are use cases for post process deduplication, and there are use cases for real-time compression. The customers need to decide where to best apply these technologies, and CORE seems to be a useful tool to help them gravitate toward the right solution for their various problems.

The idea of the formula is right, but you need to take more than vendors’ random claims for how well they shrink data for the Capacity Reduction score, and you need balance in the formula that represents users real-world priorities. Performance IS important, but is “time to compress” even the most important performance metric? Maybe time-to-decompress (which is when users feel the effect) is more important?

I don’t mind this sort of thing, right up to the point where I feel a vendor is trying to mislead or fool customers. This is right at the edge of that. Don’t you have to at least do something useful before it matters how fast you do it?