With HYPERMAX OS 5977.810.184 and later, users can access the data on fully defined nocopy targets after having been unlinked. This functionality is possible through the shared allocations. As discussed earlier, the defining process creates the shared allocations between the target volume and source or snapshot deltas.

When a target is unlinked, the allocation sharing remains in place. In other words, unlinking will not unshare the allocations. Even after unlinked, termination of a snapshot results in the target owning the snapshot delta. And an updated write to the source track results in the target owning the original track. The target also takes ownership of any shared source tracks if the source is deallocated after unlinking.

This enhanced functionality allows the user to continue to access the target data after unlinking in the same way that previously required full copy targets, but without duplicating the entire back-end data from the point-in-time to the target.

There are a few important aspects to understand about this behavior:

• Nocopy target data is valid only if the target is fully defined before unlinking. The following commands help the user determine if the defined process has completed on the target or targets:

symsnapvx –<sourcedevs> –snapshot_name list –linked

symsnapvx -<targetdevs> -snapshot_name verify -linked -defined -by_tgt

• The unlink operation does not cause any data on the target to be deallocated. This includes data that was copied during the link operation as well as data that was directly written to the target. Therefore, an unlink operation does not return any free capacity to the SRP.
• If the user wants to deallocate the data on the target or targets after unlinking, they can do so by issuing the symdev free –all command to the target volume.

Note: This is a powerful command that will completely deallocate all data on the volumes that it is issued against. Take extreme care when using this command. As a safety mechanism, the symdev free –all command requires the device to be not ready or unmapped. 

• Similarly, after terminating a snapshot, users may not see as much capacity returned available to the SRP as expected because the previous target that was sharing the snapshot deltas has taken ownership of them.
• Also, if that target happens to be in a separate SRP from the source or snapshot, the data is copied across SRPs as the target takes ownership.
• The underlying behavior exists in earlier versions of HYPERMAX OS, but the data verification testing was not completed to qualify the feature until HYPERMAX OS 5977.810.184.

This means that at earlier versions of HYPERMAX OS, users may observe the behavior described in the previous bullets. But the validity of the data on the nocopy targets after unlinking cannot be guaranteed.

• Regarding performance, this feature should be considered to perform as well as accessing linked nocopy targets.