This post is more than 5 years old
5 Posts
0
1364
Saving pool space with Nocopy clones
Folks,
We have a very large db replicated to a VMAX, running 5876 code, from the R2 we have 4 different test,dev,Backup,QA clone copies. We figured we could save a ton of space using nocopy clones, none of these environments require high performance.
The problem is the default behavior on a nocopy clone is copy on access. How do we change that behavior to copyonwrite?
We have thought about changing the whole operation and using the new -vse and making it a Snap but like the idea of being able to make it a full clone copy if the need arises. Thanks in advance.
If anyone has good documentation on the differences between a nocopy clone and the vse option that would be welcome as well.
Quincy561
1.3K Posts
0
December 10th, 2012 10:00
To change the clone to not copy on read requires an environment variable to be set, AFAIK.
Set this to enable should do it.
#
# Parameter: SYMAPI_CLONE_COPY_ON_WRITE
#
# Allowed Values: ENABLE: Sets clone nocopy mode
# to copy-on-write.
# DISABLE: Sets clone nocopy mode
# to copy-on-access.
#
# Component(s) Affected: Clone
#
# Default Value: DISABLE
LBM99
1 Rookie
1 Rookie
•
119 Posts
1
December 11th, 2012 10:00
Correct, that is where you change the nocopy mode in the Options file. The nocopy mode is determined at create time and will not be changed on existing sessions when the options file setting is changed.
"Set Mode" cannot be used on -vse sessions. But you should also understand that nocopy clones are not differential sessions, so they cannot be recreated nor restored. VP Snap (vse) sessions are differential, and are always copy-on-write; the options file setting has no effect on -vse sesisons.
Another difference is that traditional nocopy clones are charged to the source volume as a normal clone session. VP Snap sessions are charged separately, so you can still have max amount of traditional clone sessions + VP Snap sessions.
One more note; VP Snap and nocopy sessions cannot exist on the same source volume.
dietzdave
5 Posts
0
December 11th, 2012 10:00
Thank you both, we did know we couldn't recreate a nocopy clone and in fact don't want to, we have been unbinding the target devices to zero them back out before the clone is created and activated.
The first time we did this the unbind command came back in a few seconds but we couldn't rebind, watching the pool utilization it continued to drop over the next 20 min or so as the pool was actually cleared out, then we could rebind back to the pool. The next refresh cycle will show the real fruits of this effort as we should be able to stay truely thin with the copy on write access devices.
LBM99
1 Rookie
1 Rookie
•
119 Posts
0
December 11th, 2012 12:00
Clone nocopy sessions, in CopyOnWrite mode, will deallocate (zero out) the targets as the sessions are activated. This will take time too though. Can't say if it would be faster than deallocate during the unbind or not.
VP Snap also deallocates TGT during activate, and again when session is terminated.