From symrcopy -h :
-consistent Causes the source and target pairs to be consistently copied.
What does this mean (i.e. clearly without this flag, the data is not "inconsistent", so what is the consistency referring to in this context)?
-force_copy Forces a create operation even though one or more paired devices in the device file may not be large enough to contain the whole extents of the control device on a push, or the whole extents of the remote device on a pull.
If the operation is a pull, and the control device is too small, the session will be created so that it will only copy the total number of blocks that will fit into the control device.
If the operation is a push, and the remote device is too small, the session will be created so that it will only copy the total number of blocks that will fit into the remote device, if it is visible to the API host.
If I have say a 100 GB LUN that contains 50 GB of data and I create a device to migrate this to that is 60 GB in size what will happen? Will the 50 GB of data migrate without problems onto the 60 GB LUN, or will it just do a block by block copy and if the blocks are in the region at the end of the 100 GB LUN, then the end result would be corrupted and useless data.
If the end result is the possibility of corrupted and usless data on a LUN, I am finding it hard to understand in what situations the -force_copy switch could ever be useful?
The -consistent option uses Enginuity Consistency Assist (ECA) during session activation to temporarily pause I/O so that a consistent point-in-time copy can be created across all devices participatat. It's equivalent to the symclone -consistent option, which also uses ECA during activation to create a consistent point-in-time copy. For Open Replicator, the -consistent option applies when activating hot push sessions, and when turning donor_update off.
The -force_copy option would typically only apply if you first pushed data from a smaller to a larger device, and then wanted to pull it back from the larger device to the smaller device. For example, if we pushed the contents of a 50GB control device to a 100GB remote device, we know that only the first 50% of the remote 100GB device has data, so we can safely pull back that data from the 100GB device to the 50GB device with the force_copy option. If a host wrote new data to the latter half of the 100GB device prior to pulling back with force_copy, Open Replicator would not capture that data.
Hope that helps,
Hi Sean, that's a lot clearer thanks.
I'm still finding it hard to imagine a use-case where I would ever copy a customers data to a larger device, then specifically never write any data to that device, and then write that data back to a smaller device, but thanks for the clarification (so I don't think I can ever see a reason where I will ever use either of these switches then, as I primarily do cold pull / hot pull where an EMC customer is migrating data to a new array to decomission an old array).
No problem Roy.
Yeah, there aren't many use cases for the -force_copy flag. One that I could think of would be a case where you're migrating from a VMAX to a VNX, and you can't match up the LUN sizes exactly, so the VNX LUNs are slightly larger. If you perform your migration via hot or cold push, then cutover the host to the VNX, but don't expand the host partition/filesystem into the "extra" space on the slightly larger LUN, and you decide you want to rollback the migration (move back to the VMAX) -- you could use Open Replicator to pull the changed data back from the VNX and then move the host back to the VMAX. This is definitely a corner case, but it would require the -force_copy option.
Thanks. Both good points @Sean / @dynamox. I see those both make sense.
I do see a few rare cases along the same lines as you say Sean, as customers quite often use a migration to expand a LUN (so they might ask to migate a 500 GB LUN to a 700 GB on the new array), so I push/pull to the larger LUN as normal, and if that copy was untouched *and* something happened to the original data *and* they wanted to rollback to the old array, I guess that -force_copy could be an option (but yes, these are very rare as migration events generally involve migrating the data and then cutting over the host to the new array).
we ran into an issue where the target LUN size (new vmax) is smaller by 2 MBs compared to source LUN size (old vmax). any idea force_copy might be an option in this scenario? we're performing hot push migration from old to new vmax array and its failing due to 2 MBs mis-match mostly by 1 or 2 cylinder mis-match.
any suggestion please?
thanks in advance,
+1 what @dynamox said You'd be risking data loss by using force_copy in this instance... if there is any data on the last few blocks of your source devices, that data will not be copied to the new VMAX devices.
thanks for your reply.
unfortunately, non standard device sizes were created on old vmax (single not many) by manual but later we provision storage with internal automation tool with proper lun sizes in terms of cylinders. So don't want to change anything in current code base and rather look for the alternative options within OR otherwise perform host based migration to overcome this issue.