![3par ssmc convert raid type 3par ssmc convert raid type](https://slideplayer.com/slide/10202871/34/images/4/HP+3PAR+–+High+level+OS+Evolution.jpg)
So we trade performance for data integrity in this case and in a majority of workloads its no big deal. the read process is expensive as it generates IOs though so with SSDs its relatively low impact to do some reads, in spinning disks however not so much. This is because of hash collision possibilities (basically two pieces of different data with the same checksum) and its the only way to be sure the data is truly duplicate.
3par ssmc convert raid type update#
if they match then great we update some tables and pointers and away we go. Instead to ensure data integrity when we detect a piece of data with a duplicate checksum we reread the data from media and the asic does a bit for bit compare on the incoming data and the data on disk. Its the same mechanism we use for thinprovisioning just applied to dedupe. The internal express lookups are not a bottle neck today and all asic based. The actual issue is around data protection. Dedupe on HDD will most likely not come to Gen4 ASIC based 3PAR as for Gen 5 I cant say. Also the SSMC tools are a little cryptic to understandig the dedupe ratio you are getting. dedupe ratios are highly specific to the data type. I would be curious to know what happened with performance and your exact config.
![3par ssmc convert raid type 3par ssmc convert raid type](https://image.slidesharecdn.com/hp3parstoreservmanagementconsole2-150429161635-conversion-gate01/95/hp-3par-ssmc-21-38-638.jpg)
Unless your a heavy write workload you really shouldn't have an issue with dedupe performance. Write throughput on our arrays was atrocious and dedupe ratios were even worse. That said it will be a cold day in hell before I enabled dedupe on a 3par again. This is also why dedupe doesn't currently work with AO, takes to long to rehydrate the data to move to the lower performing tiers.įrom what I understand of it they felt performance was too low to want to allow the system to do it at the current time. They were exploring requiring having some flash for the dedupe tables to live on in order to increase the performance to what they deemed were acceptable levels. From what I understand of it they felt performance was too low to want to allow the system to do it at the current time. The reason they are not doing dedup on FC and NL yet, and I say yet because last I knew it was still being evaluated, is because of the time factors involved in writing to the dedupe meta tables and rehydrating the data on those disks. Does it justify the extra cost, not really in my opinion. There is some other firmware trickery going on as well I can't go into as well. The drives the 3PAR is coming with are using the overprovisioned space within the drive as usable space from the manufacture with different firmware, netting a larger drive than you get with the Compellent. Except you aren't getting the same drives as the Compellent or consumer.