The Difference Between Storage Foundation SmartMove and Hardware-based 'Zero Reclaim' Solutions

[Kimberley]

Written by: Thomas Cornely

What’s the Hardware Zero Reclaim functionality?  It basically refers to the array’s ability to scan a thin lun and look for pages of physical storage that contain ‘all zeroes’. When they find such a page, they reclaim the page (i.e. detach it from the thin lun) and put it back in the free pool. They can do this because the array returns ‘0’ to any I/O read it received on ‘unallocated space’ in a thin lun.

Who’s doing it?

Most hardware vendors are coming out with similar functionality. IBM XIV was the first one to have it. 3PAR has it. NetApp has it (they actually have true dedup in the array). Now Hitachi has it.

What are limitations of the Hardware Zero Reclaim functionality?

Hardware Zero Reclaim relies on the presence of 0 in the array to do the reclamation. In the context of a thick to thin migration, the process would be as follows:

• start with 1 TB thick LUN that’s 40% utilized
• migrate 1 TB and end up with a fully allocated 1 TB thin lun (not thin at this stage)
• trigger ‘Hardware zero reclaim’: any contiguous span of 0 that’s as a big as a chunk of storage will get reclaimed.
• If all unused space on the source LUN was all 0, then you would reclaim close to 60% of the storage.

Notice that you first have to migrate and effectively ‘allocate’ 1TB of space on the thin lun. The model is “allocate first, hopefully reclaim later”.

To make matters worse, unused space on the source LUN is reclaimed IF AND ONLY IF it contains all 0. This condition typically isn’t true. In most cases, the unused space on the source LUN contains “anything”. Either the data that was there before it was deleted in the file system. Or the random information that was on disk before it ever got used. Not 0.

The second condition is also important: the array will reclaim only if a full chunk of 0 is found. In the case of Hitachi, that would mean finding a 42 MB contiguous span of 0 on the LUN. The chance of that just happening is even lower than finding unused space that also happens to be 0.

How is SmartMove Better?

SmartMove optimizes resource utilization (host CPU, SAN bandwidth, storage controller I/O, disk space) during the migration. The reclamation of unused space occurs AS you migrate. As a result, when migrating a 40% 1 TB LUN to a thin LUN, you only move 400GB and you only need 400 GB of storage on the thin provisioning array side. You save IMMEDIATELY, as opposed to the ‘allocate first and hopefully reclaim later’ approach of the hardware-based alternative.

The other and bigger benefit is that SmartMove reclaims ‘all’ unused space independent of what the unused space actually contains. Most unused space contains “anything” and only SmartMove is able to know that a block that contains “anything” is unused and doesn’t need to be copied.

Based on this, only SmartMove can guarantee that after the migration of the 40% utilized 1 TB LUN, you will end up with only 400 GB of storage in the thin array.

To be fair, SmartMove has one limitation that doesn’t apply to the Hardware Zero Reclaim: SmartMove requires a mounted VxFS (or NTFS on Windows) file system to work.

 Written by: Thomas Cornely