Reply to post: What is an AFA? (according to SNIA)

What is an AFA? (according to SNIA)

Follow the link to the SNIA doc shared by E8 and you'll find none of the systems listed are 'real' AFA's anyway! ;-)

...

What is an AFA?

- All-Flash-Array

- Not SSD (form-factor flash drives)

- Built from Function-designed flash modules

...

By that standard everyone listed is disqualified for not being a SNIA AFA! But this might just be because the doc was authored with a focus on the non SSD IBM FlashSystem.

So forgiving SNIA for the editing miss, they do a pretty good job defining workload testing definitions; attempting to simulate mixed workloads with a variety of read/write ratios and a wide distribution of block sizes. However, many real world applications tend to have different block sizes for Reads and Writes (I'd say always for mixed workload environments) and very hard to simulate precisely with a synthetic test, but still less risky for most than chucking a new system into production to find the real answer.

EMC, Infinidat and E8 state that they used an 80% Read workload for the published results at 8 & 16KB, I'd wager these weren't extracted from the mixed block SNIA workload run, across the board; "80/20 read/write ratio, all sequential, mixed block sizes matching your actual distribution, 5:1 reducible data, some I/O banding with drift". So, the results here appear to be more of a hero test for a specific IO profile than a meaningful real world comparison, but perfectly valid for a single Tier-0 app with that IO profile, hmm what's E8's sweet spot again?.

Last point - one person's 5:1 reducible data, is another person's 7 or even 10:1 reducible data; pretty much every vendor uses different data reduction secret sauce, and some are more granular and efficient than others, achieving higher reduction rates for the same application data. For a given workload profile a higher reduction ratio can mean higher performance on a system, therefore testing with a 5:1 reducible dataset across the board still doesn't give you a real-world apples to apples comparison.

Ignore the vendor spin and test as close to real world for both your data and system behaviour as you can!