Unsolved
This post is more than 5 years old
5 Practitioner
•
274.2K Posts
0
7655
Unable to unlink snapshot VMAX3
hi,
we have a backup procedure that goes like this:
we have a SG source and a SG target.
for reference we will call them SG_src and SG_tgt.
we are terminating any SnapVX session that exists on the SG_arc.
we take a SnapVX snapshot from SG_src.
afterwards we are linking the snap to the SG_tgt.
in this phase, we should be starting the backup procedure, but for now we are not starting it because we want to make sure that the method of working with SnapVX works good.
after the backup phase, we are unlinking the snap from SG_tgt and the backup procedure is done.
now for the issue - for some reason, when we try to unlink the snap from the SG_tgt we get an error that the snap cannot be unlinked unless the Symmetrix force flag is used.
we don't really want to use the force flag because we might destroy something important, but we know that our procedure should work ok.
we tried to insert s sleep mechanism to our procedure, and it turns out that after 8 minutes the snap unlink command works.
Does anyone know why it takes time to issue that unlink command?
FYI - before the unlink command is issued we are making sure that all the devices in the SG_tgt are in linked state.
Thank you!
KW160
121 Posts
3
June 7th, 2018 09:00
Very likely the Background Define process is still occurring during those 8 minutes. Here's an explanation of that process:
For HYPERMAX OS, a linked target must be fully defined before you can create
snapshots off of it. When a target is first linked, all of the tracks are undefined. At this
point the target does not know where in the SRP the track is located, and host access
to the target must be derived from the SnapVX metadata. A background process
eventually defines the tracks and updates the thin device to point directly to the track
location in the source device's SRP.
You're free to use the linked target normally even while the background define is in progress. Please note however that if you do choose to force the link to terminate prior to define completion the link target volume data should be considered invalid at that time.
PedalHarder
465 Posts
1
June 7th, 2018 19:00
Agree with KW160.
Note that in Solutions Enabler 9.0 there is an additional flag indicator on the SYMSNAPVX command output that indicates if the background define process is active, so it's more visible now. Check out the (B) indicator in the flags field in the output.
There is a verify -defined parameter in SYMSNAPVX that can be used for checking via batch scripts too.
Anonymous
5 Practitioner
5 Practitioner
•
274.2K Posts
0
June 10th, 2018 09:00
Thank you for your replies!!
it helped us better understand the SnapVX mechanism.
As for a solution regarding the (B) flag in Solutions Enabler 9.0, we are currently running Solutions Enabler 8.4.
is there a way to check in that version if the background define process is still undergoing?
if we run the symsnapvx verify -linked command we will get a result stating that the snap is in Linked state, but the background process might still be running..
PedalHarder
465 Posts
1
June 11th, 2018 20:00
The Background state and verification information is new to version 9.0 of Solutions Enabler. Note that Se 9.0 was announced with Microcode release 5978. Both the new microcode and the new SE version are needed to exploit the synanapvx background functionality.