Planning for thin provisioning

There is nothing wrong with RAID6.  However it is possible you would need 4 times as many disks and DAs to support the same workload as RAID1.  RAID5 can require twice as many disks and DAs as RAID1.

There is a good document on Powerlink on the best practices, as well as a performance presentation given at EMC World that worth looking at as well.

how the "4 times  OR 2 times od disk/DA" is applicable to RAID6 and RAID5?Can you tell your theory please? Is that applicable to only Thin provisioning?

RAID1 write = 2 simple writes to disks

RAID5 write = 4 IOs to disks (2 reads 2 writes) + 2 XOR operations, twice the IOs of RAID1

RAID6 write = 6 IOs to disks (3 reads 3 writes) + 3 XOR operations, three times the IO of RAID1

Quincy56,

shouldn't this be:

RAID1 write = 2 simple writes to disks

RAID5 write = 4 IOs to disks = (data read, parity read, new data write, parity write) = twice the IOs of RAID1

RAID6 write = 6 IOs to disks = (data read, 2 x parity read, new data write, 2 x parity write) = three times the IO of RAID1

Mentioning the XOR is double since you already mentioned an extra read and write.

Agree ?

Just reading the old data and parity doesn't create the resulting XOR data that is needed.  This must be calculated from the old and new data/parity and isn't free.

Ahhhhhhh, that's what you meant ! Not the writing of the data, but the actual cpu cycles you need to get the data in the first place !

I'm always told that computing the XOR data (the parity) in a Symm can be ignored since the hardware can do this very fast. In a Clariion you do need to consider this however, snice you only have 2 storage processors.

Yes, the CPU can do this very fast, and calculating the XOR doesn't put more load on the disk, but does put load on the DA.  If the DA isn't near saturation, it isn't an issue, however it can make the DA reach saturation faster.

On DMX, the fiber drives could do XOR in the drive.  The drives did the XOR only when the DA was busy.  The EFDs or SATA never had this ability.

On VMAX, the XOR is always done by the DA.

I thought from the DMX series on up the Xor is done in cache and only if the processors are too busy is it teh Xor pushed over to the DA's?

In the drives ? Waaw, so in case a drive would need to do XOR for a stripe, doesn't it need the data from the other drives participating in that particular symdev ? It seems very inefficient this way.....

Also this drive XOR was only for RAID5, it was never used for RAID6.

You do not need all the data from all the drives to calculate the XOR for a single write.  The way the drive XOR worked was the new data was sent to the data drive with a special SCSI command.  This command told the data drive to take the new data, XOR it with the old, save the resulting parity in the buffer and write the new data.  Then it would send the parity result to cache.  This would then be sent to the parity drive, along with another special SCSI command telling the parity drive to take this new parity, XOR it with the old, and write the new parity.  So no XOR performed by the DA, but still two reads and two writes by two drives.

This took a load off the DA, but increased response time, as when the drive was performing these XORs, it could do nothing else.  Also these two IOs had to be performed one right after the other.  To support this function EMC also had to have special code for the drives.  It was a good idea when CPUs were slow and expensive, now CPUs are much faster and a lot cheaper.  And we can now have one common SCSI code for all drives across all EMC platforms, rather than having a special one for only Symmetrix.

Wow, I never knew this ! Cool. Too bad these nice features are now gone.