Persistent reclaim

Hi,

Are you sure the Reclaim worked for the device that has the SRDF session active ? The command might appear to work, but the space would not be reclaimed.

And for the Local replication :

Reclamation will not be performed on tracks that participate in a local replication session, including TF/CLone and TF snap. If any track is protected the entire device will not be reclaimed. Once the protection is cleared on all tracks, it can be reclaimed.

I shall perform more tests related to ur scenario and reply back

Regards,

Arjun

Yes Arjun.... Reclaim has since long been working on an active SRDF replicated LUN for us. We have done so for some 300 odd LUNs. (and the space difference before and after reclaim was realised on all of these LUNs).

And, the devices that are failing reclaim with the persistent bit set are failing even after the replication is broken and also, that these devices DO NOT have any timefinder\BCV activity on them.

Thanks,

SreeHari

Prior to Enginuity 5876.159.102, zero space reclamation was not supported on actively replicating SRDF volumes. The link needed to be suspended prior to running the reclamation operation. With 5876.159.102 and later, however, the SRDF relationship can remain active and the reclaim operations will occur against the devices at both sites. All Symmetrix arrays in the SRDF relationship must be at 5876.159.102. Additionally, zero space reclamation will not be performed on tracks that participate in a local replication session, including TimeFinder/Clone and TimeFinder/Snap.

Ptambe wrote:   Prior to Enginuity 5876.159.102, zero space reclamation was not supported on actively replicating SRDF volumes. The link needed to be suspended prior to running the reclamation operation. With 5876.159.102 and later, however, the SRDF relationship can remain active and the reclaim operations will occur against the devices at both sites. All Symmetrix arrays in the SRDF relationship must be at 5876.159.102. Additionally, zero space reclamation will not be performed on tracks that participate in a local replication session, including TimeFinder/Clone and TimeFinder/Snap.

if i run reclaim on the R1, will it reclaim the r2 also?

hello saurabh,

Prior to 5876.159.102, where you must suspend the SRDF relationship for zero-space reclamation, any tracks that are reclaimed against a source R1 device are also marked as invalid. When the SRDF links are resumed with an incremental establish, these tracks are copied to the R2 side where a zero-reclaim automatically occurs against the target device.

With 5876.159.102 and later, where zero-reclaim can execute with SRDF active, the tracks reclaimed on the source R1 are not invalidated. This means that if the SRDF relationship is suspended during a reclaim operation against the source device, an incremental establish will not propagate the changes to the target automatically. A full establish propagates these changes.

Source: Whitepaper - EMC SYMMETRIX VMAX VIRTUAL PROVISIONING SPACE RECLAMATION AND APPLICATION CONSIDERATIONS

thanks.

thanks rohan

I have 2 vmax arrays running 5876.251.161 on each array.

If I don't suspend replication and run a zero reclaim on the R1, will the changes propagate to the R2? or will I need to run a zero reclaim on the R2 as well?

Thanks.

Thanks! That's great info.

thanks symcliguy. the whitepaper didn't really address that.

I suppose, if a device group suspended during the zero reclaim, then a full establish would be necessary? or could I just restart the zero reclaim on the R1?

You only need to run the zero space reclaim on the R1 side.  Changes will propagate to the R2 side.