TECHNICAL NOTES

EMC HYPERMAX OSTM Local Replication

TimeFinder SnapVX and TimeFinder Emulation

H13697
A08
April 2016

This Technical Note explains the EMC HYPERMAX OS Local Replication, including
TimeFinder SnapVX and TimeFinder Emulation Support.

Executive Summary.................................................................................. 2
TimeFinder SnapVX .................................................................................. 2
Implementing TimeFinder SnapVX ............................................................ 18
Emulation Support for TimeFinder Mirror, Clone, and VP Snap ................... 23
Conclusion .............................................................................................. 24
References .............................................................................................. 25
Appendices ............................................................................................. 26

Executive Summary

Executive Summary
EMC TimeFinder software delivers point-in-time copies of volumes that can be used
for backups, decision support, data warehouse refreshes, or any other process that
requires parallel access to production data.
Previous VMAXTM families offer several different TimeFinder offerings, each with their
own characteristics and ideal use cases. These offerings also have several
similarities, the main one being that they each require a target volume to retain
snapshot or clone data.
TimeFinder in HYPERMAX OS 5977 introduces TimeFinder SnapVX which combines
the best aspects of the previous TimeFinder offerings, adds some new ease-of-use
features, and increases scalability.
SnapVX provides very low impact snapshots and clones for VMAX LUNs. SnapVX
supports up to 256 snapshots per source volume, which are tracked as versions with
less overhead and simple relationship tracking. Users can assign names to identify
their snapshots, and they have the option of setting automatic expiration dates on
each snapshot.
SnapVX provides the ability to manage consistent point-in-time copies for storage
groups with a single operation. Up to 1024 target volumes can be linked per source
volume, providing read/write access as pointers or full-copy clones.
TimeFinder in HYPERMAX OS also provides compatibility modes for users who rely on
their TimeFinder Mirror, Clone, or VP Snap command scripts. This will allow users to
use their existing scripts while learning how to take advantage of the new features of
SnapVX.
This document describes TimeFinder features for business continuance and
implementation guidelines, including restrictions and limitations for this product.
The features discussed are valid for HYPERMAX OS 5977 on VMAXTM All Flash and
VMAX3TM Series arrays.

Audience
This technical note is intended for storage administrators, database administrators,
and technologists who have an interest in understanding the concepts surrounding
Local Replication in VMAX All Flash and VMAX3 Family storage arrays.

TimeFinder SnapVX
Local replication with SnapVX starts out as efficient as possible by creating a
snapshot, a pointer based structure that preserves a point in time view of a source
volume. Snapshots do not require target volumes, share back-end allocations with
the source volume and other snapshots of the source volume, and only consume
additional space when the source volume is changed. A single source volume can
have up to 256 snapshots.

2 EMC HYPERMAX OS Lo c a l Rep lic a tio n

TimeFinder SnapVX

Each snapshot is assigned a user-defined name and can optionally be assigned an

expiration date, both of which can be modified later. New management interfaces
provide the user with the ability to take a snapshot of an entire Storage Group with a
single command.
A point-in-time snapshot can be accessed by linking it to a host accessible volume
referred to as a target. The target volumes are standard Thin LUNs. Up to 1024 target
volumes can be linked to the snapshot(s) of a single source volume. This limit can be
achieved either by linking all 1024 target volumes to the same snapshot from the
source volume, or by linking multiple target volumes to multiple snapshots from the
same source volume. However, a target volume may only be linked to a single
snapshot at a time.
By default, targets are linked in a nocopy mode, but can be linked in a copy mode to
create full-copy clones. Snapshots can be cascaded from linked targets, and targets
can be linked to snapshots of linked targets. There is no limit to the levels of
cascading and the cascade can be broken at any point, with limitations that are
discussed later.

Terminology
The following are explanations of terms that are commonly used
throughout the paper:
Storage Resource Pool (SRP): A collection of data pools which
provide physical storage for thin devices. SRPs are managed by
Fully Automated Storage Tiering (FAST).
Source Volume: A LUN that has SnapVX snapshots from it, either
with or without linked targets.
Snapshot: A preserved point-in-time image of a source volume. A
snapshot uses pointers in cache to indicate which version of a
track is applicable to the specific point-in-time; either a track that
resides on the source volume, or a snapshot delta.
Snapshot Delta: A point-in-time version of a source volume track
that was preserved during a host write to a source volume that
had an active snapshot.
Linked Target Volume: A LUN that is linked to a SnapVX snapshot
in order to make the point-in-time of the snapshot accessible to
the host. Linked targets can have one of two modes:
Nocopy Mode: Does not copy data to the linked target volume but still makes the
point-in-time accessible via pointers to the snapshot. The point-in-time
image will not be available after the target is unlinked because some target
data may no longer be associated with the point-in-time1.
1

Please see Appendix D for changes to the nocopy target functionality

beginning in the HYPERMAX OS Q1 2016 Service Release.

EMC HYPERMAX OS Lo c a l Rep lic a tio n

TimeFinder SnapVX

1) Copy Mode: Copies all relevant tracks from the snapshots

point-in-time to the linked target volume to create a
complete copy of the point-in-time that will remain
available after the target is unlinked.

Creating Snapshots
TimeFinder SnapVX allows snapshots to be taken without the use of a target volume.
The snapshots are made as efficient as possible by sharing point-in-time tracks,
which are called snapshot deltas. The snapshot deltas are stored directly in the
Storage Resource Pool (SRP) where the source volume resides. Each snapshot will
use pointers to reference snapshot deltas appropriate for the specific point-in-time
image.
SnapVX Snapshots are created with the symsnapvx establish command. As part
of the establish command the user will define a name for the snapshot. The userdefined name may be up to 32 characters long and may include alpha and numeric
characters, dash and underscores. The name is not case sensitive.
Figure1 depicts a source volume with three snapshots.

Figure 1. Volume with three snapshots

Generation Numbers
It is possible to have multiple snapshots by the same name for the same set of
source volumes, and generation numbers will be used to identify the different
snapshots. It is important to understand how generation numbers are applied when
deciding to either reuse snapshot names or to use unique names for each snapshot.
Generation numbers are relative to existing snapshots at the time of creating or
displaying snapshots, and will change as snapshots are created and terminated.
4 EMC HYPERMAX OS Lo c a l Rep lic a tio n

TimeFinder SnapVX

When a snapshot name is reused, the new session will become Generation 0 and all
previous sessions by the same name will have their generation numbers incremented
by a value of 1. Similarly, if a more recent snapshot is terminated, all older
snapshots will have their generation numbers decreased by a value of 1. The most
recent snapshot will always have a generation number of 0. This is advantageous
because after creating a new snapshot, the user will always know that it is Generation
0 and will not have to search for the specific snapshot.
For example, if a user creates a snapshot called hourly_backup at 1PM. This
snapshot would be Generation 0. Then at 2PM they create another snapshot and
reuse the name hourly_backup. At this point, the 1PM snapshot would become
Generation 1 and the 2PM snapshot would be Generation 0. Similarly, at this point if
the 2PM snapshot (Generation 0) was terminated, the 1PM snapshot would again
become Generation 0.
Reusing snapshot names and employing generation numbers can be very useful. A
user could create a certain amount of generations for a specific snapshot, and then
every day they could create a new one and terminate the oldest, using the same
commands each day and making scripting simple.
However, the user must be cognizant of the fact that the generation numbers are
dynamic; creating or terminating snapshots may cause generation numbers of other
snapshots to change. This could be problematic in situations where multiple users
create snapshots on the same set of volumes, especially in situations where a single
volume is in multiple groups (Storage Groups, Device Groups, Composite Groups,
etc). Just as with any other feature or option, the user must make the best choice for
their environment.

Time-to-Live (TTL)
The user also has the option of defining a time-to-live (TTL) value on each snapshot,
which acts as an expiration date. Snapshots will automatically terminate when the
TTL expires, assuming the snapshot does not have any linked targets. If a snapshot
has linked targets and the time-to-live has expired, the snapshot will terminate when
the last target is unlinked.
TTL values can either be set to a specific date (-absolute) or a specified number of
days (-delta). When a user sets TTL to a specific date, Solutions Enabler will
internally use a delta that is calculated from the specified date and the current host
time. This internal conversion eliminates the need for users to synchronize clocks or
calculate times between servers and the storage array. Time-to-Live values can be
specified when the snapshot is established, and can also be set or changed on
existing snapshots.

Host Writes to Source

Host writes to source volumes will create snapshot deltas in the SRP. Snapshot
deltas are the original point-in-time version of each track that has been updated
since a snapshot was established. Multiple snapshots can share a single snapshot
delta if they are all active at the time a source track was updated. So, if a source track
that is being updated needs to be preserved by multiple snapshots, only one
snapshot delta is needed. This sharing allows the snapshots to be as space-efficient
as possible.
EMC HYPERMAX OS Lo c a l Rep lic a tio n

TimeFinder SnapVX

The output of command symsnapvx list detail and other commands will report
the amount of deltas for each snapshot. The symsnapvx list detail output also
has a Non-Shared Tracks field that provides the number of tracks uniquely
allocated to each snapshot. This information is valuable because it can be used to
determine which snapshots are using the most non-shared space and will be most
beneficial to terminate in the event of needing to free some space in the SRP. Only
non-shared space is freed from the SRP when a snapshot is terminated.

Redirect-On-Write
SnapVX introduces Redirect-On-Write (ROW) technology to TimeFinder. When a
source track is written to and the original data needs to be preserved for a
snapshot(s), the new write will be accepted and asynchronously written to a new
location in the Storage Resource Pool (SRP). The source volume will now point to the
new data while the snapshot(s) will continue to point to the original data (the
snapshot delta) in its original location.
Redirect-On-Write is illustrated in the following figures. Figure 2 shows the source
volume and snapshot both pointing to the same location in the pool before the track
is updated.

Figure 2. Source track prior to host update

Figure 3 shows the source pointing to the new location in the pool after the host
write, while the snapshot continues to point to the original location.

Figure 3. Source track and snapshot delta after Redirect-On-Write

SnapVX will use Asynchronous Copy on First Write (ACOFW) rather than ROW in
certain situations, specifically to prevent the new write from being directed to a lower
tier. For example, if the original track resides on the Flash Drive tier, it may be copied
to a lower technology drive to allow the new write to be applied to the original
location on the Flash tier.

Replication Cache
A portion of the metadata in cache is dedicated for Replication Data Pointers (RDP)
which keep track of the snapshot deltas in the SRP. This portion of metadata is
6 EMC HYPERMAX OS Lo c a l Rep lic a tio n

TimeFinder SnapVX

called Replication Cache. If Replication Cache is exhausted, snapshots may begin to

fail.
Replication Cache is used by SnapVX snapshots and VP Snap Emulation sessions.
Replication Cache usage increases as SnapVX and VP Snap source devices are
written to, as there is more point-in-time data to manage. SnapVX Linked Targets and
Clone Emulation sessions do not have an effect on Replication Cache usage.
It is important to understand that Replication Cache resources are not immediately
released upon snapshot termination. The process may take some time as it is
designed as a background process so to not take away processing resources from
other higher priority operations within the array. Therefore, current Replication Cache
usage should be checked before creating new snapshots immediately after
terminating existing snapshots.
All systems follow the same algorithm to determine the percentage of metadata that
will be dedicated to Replication Cache. Systems that have very high snapshot usage
may be candidates to have the Replication Cache portion of metadata increased.
However, this is not a typical use case. In the large majority of systems, the standard
algorithm will provide enough Replication Cache for the environment. Please contact
your local EMC Service Representative if you feel your environment requires increased
Replication Cache.
Monitoring Replication Cache Usage
Solutions Enabler 8.2 and Unisphere for VMAX 8.2 introduce tools to monitor
Replication Cache Usage. These tools are only available when used with systems
running the HYPERMAX OS 2016 Q1 Service Release.
The symcfg list v output has a field that shows the current Replication Cache
usage:
Symmetrix ID: 00019680XYZ (Local)
Time Zone
: Eastern Standard Time
Product Model
: VMAX100K
Symmetrix ID
: 00019680XYZ
Microcode Version (Number)
: 5977 (17590000)
--------------------< TRUNCATED >-------------------Max # of DA Write Pending Slots
: N/A
Max # of Device Write Pending Slots :
85622
Replication Usage (Percent)
:
12
Figure 4. symcfg list v

SE 8.2 also provides a new alert ID 1222 to report when Replication Cache usage has
exceeded the specified thresholds. The default threshold values are the same as the
default values for other SE thresholds alerts. The user also has the ability to specify
other values. However, the alerts are not enabled by default, and need to be enabled
by the user.
The default threshold values are as follows:

FATAL severity = 100%

EMC HYPERMAX OS Lo c a l Rep lic a tio n

TimeFinder SnapVX

CRITICAL severity >= 80%

MAJOR severity >= 70%

MINOR severity >= 65%

WARNING severity >= 60%

Unisphere for VMAX reports the Replication Cache usage on the summary page of the
Data Protection Dashboard:

Figure 5. Unisphere for VMAX Protection Dashboard Summary Page

Alerts are also available in Unisphere for VMAX 8.2. The System Alerts have the
following threshold values and are enabled by default:

FATAL severity = 100%

CRITICAL severity >= 80%

Warning severity >= 60%

8 EMC HYPERMAX OS Lo c a l Rep lic a tio n

TimeFinder SnapVX

Figure 6. Unisphere for VMAX Default System Alert

Users also have the ability to create custom alerts with their own threshold values:

Figure 7. Unisphere for VMAX Custom Alert

With the Q1 2016 Service Release of HYPERMAX OS, the system will call home to the
EMC Support Center when Replication Cache usage reaches new predetermined
thresholds.

Shared Allocations
VP Snap in Enginuity 5876 introduced backend allocation sharing between VP Snap
target volumes; multiple snapshots from a source volume can share point-in-time
versions of a track. A backend allocation could be shared by up to 16 VP Snaps.
Allowing multiple targets to reference the same shared copy provides cost-effective
space savings. Shared track values on thin pools could be seen with Solutions
Enabler and Unisphere for VMAX.
EMC HYPERMAX OS Lo c a l Rep lic a tio n

TimeFinder SnapVX

SnapVX in HYPERMAX OS 5977 greatly enhances this shared allocation capability. A

snapshot delta can be shared between snapshots and shared with target volumes,
and a source allocation can be shared with target volumes. And there is no limit to
the amount of volumes that can share a particular allocation.
Sharing of a snapshot delta between snapshots is similar to that of VP Snap at 5876;
when a source write comes in and the original track needs to be preserved as a
snapshot delta for multiple snapshots, only a single snapshot delta will need to be
created.
However, nocopy linked targets will begin to share tracks with the source volume
and/or share snapshot deltas for the specific point-in-time as part of the defining
process, which is discussed on page 12. The targets will be added to sharing at the
time of link, independent of source track updates.
If a source track that is being shared with a target (or multiple targets) is updated, the
existing track will be preserved as a snapshot delta and will continue to be shared
with the target(s).
Writes to a target will be applied only to the specific target. If the write is to a track
that is being shared then the track for the specific target will be split from the shared
group, and any other snapshots and/or targets continue to share the original shared
track.
Reporting of shared track counts on pools or SRPs by Solutions Enabler or Unisphere
for VMAX is not applicable in HYPERMAX 5977. However, some Solutions Enabler
displays will report shared track counts on pools for backwards compatibility to older
arrays.
Solutions Enabler instances and Unisphere for VMAX will report the non-shared track
count on each snapshot. The non-shared count is the most important value because
non-shared snapshot deltas will be discarded when the snapshot is terminated,
which will free space in the SRP.
Note: Please see Appendix D for changes to the nocopy target functionality beginning
in the HYPERMAX OS Q1 2016 Service Release.

Linking Target Volumes to Snapshots

A target volume can be linked to a snapshot when a user wants to present a point-intime copy to a host. Multiple targets can be linked to a single snapshot. Writing to a
linked target will not affect the point-in-time of the snapshot; should the data on the
linked target be corrupted by the user activity the target can be relinked to the
original snapshot. Figure 8 depicts a source volume with three snapshots, and a
target linked to the 3rd snapshot.

10 EMC HYPERMAX OS Lo c a l Rep lic a tio n

TimeFinder SnapVX

Figure 8. Target linked to a snapshot

Targets can be linked in either copy mode to create full-volume copies that will
remain available even after a snapshot is terminated, or in nocopy mode to create
space-saving copies that will only allocate space due to host writes to the target.
Host writes to a source volume that has a snapshot with a target linked in nocopy
mode will only preserve point-in-time tracks as snapshot deltas, and will not cause
any tracks to be copied to the linked target. The linked targets will access the
preserved point-in-time by sharing the snapshot delta allocation.
Snapshots that have linked targets cannot be terminated. The user needs to unlink
the target first and then the snapshot can be terminated.
Linked targets can be SRDF R1 volumes, as long as the link command is in copy
mode.

Relinking
The relink command provides the capability to perform incremental refreshes of
linked targets. The relink command can also be used to link a target to a different
snapshot of the same source volume. The relink command can be issued to both
copy and nocopy mode linked targets. This functionality provides an easy way for
users to check different points-in-time if they are unsure which one is the best for
them to access.
Please note that, just like the link command, relink will be in nocopy mode by
default unless the user specifies copy, regardless of the mode of the original link.

EMC HYPERMAX OS Lo c a l Rep lic a tio n

11

TimeFinder SnapVX

Unlinking
The unlink command is used to break the relationship between a snapshot and a
linked target. Copy mode linked targets can be unlinked once copying is complete
and will retain a full, useable point-in-time copy of the source volume.
After a nocopy linked target has been unlinked, the target data should not be
considered valid since a considerable amount of the data may not be associated with
the point-in-time1.
1

Note: Please see Appendix D for changes to the nocopy target functionality
beginning in the HYPERMAX OS Q1 2016 Service Release.

A target volume that has cascaded snapshots can only be unlinked once the target
has completely copied. In the case of a nocopy linked target that has cascaded
snapshot(s), the user will need to set mode to copy, then unlink after copy has
completed2. Cascaded snapshots are discussed further on page 14.
2

Note: This restriction has been removed in the HYPERMAX OS Q1 2016 Service
Release. Beginning with this version of HYPERMAX OS and going forward, users can
unlink nocopy targets that have dependent/cascaded snapshots.

Defining State
SnapVX introduces a new concept of a defined state for linked target tracks.
Defining may aid performance of host access of target tracks that have not yet been
copied to target by presenting data directly from the SRP and eliminating the need for
a redirect to source or snapshot.
The point-in-time of a snapshot is immediately available through the target volume as
soon as it is linked. However, its track tables will still be pointing to its old track
locations and all tracks are considered undefined. Shortly after linking, a
background defining process will change the pointers of each track to reflect the
location of the appropriate track version for the specific point-in-time. The defining
process is what creates shared allocations between the target and tracks on source
and/or snapshot deltas.
Figure 9 illustrates the defining process. The target is linked to snapshot 2. The first
two tracks on the linked target volume have been defined and point directly to the
data in the SRP. The last two tracks on the linked target volume have not yet been
defined and are still pointing to the snapshot. Note that an undefined track could
point to a track on source rather than snapshot if that is the appropriate version of
the track for the specific point-in-time represented by that snapshot.

12 EMC HYPERMAX OS Lo c a l Rep lic a tio n

TimeFinder SnapVX

Figure 9. Tracks Defined

Defining applies to both copy mode and nocopy mode linked targets. In the case of
copy mode linked targets, the copy will begin after the defining process has
completed.
The point-in-time of the snapshot is immediately available when the target is linked.
The user does not need to wait for the target volume to be defined before accessing
the point-in-time. A write to an undefined target track will invoke the defining
process for the track. And a read to an undefined target track will be redirected to the
appropriate point-in-time version of the track via either the snapshot or the source
volume.
The user can check for the defined state of a linked target with the following
command:
symsnapvx sid verify sg snapshot_name linked -defined

Linking Larger Target

A target volume that is larger than the source volume can be linked to the snapshot in
either copy or nocopy mode. This functionality is enabled by default. There is an
environmental variable SYMCLI_SNAPVX_LARGER_TGT that can be set to prevent
larger targets from being used.

Source Volumes / Linked Targets SRP Relationships

Source volumes and linked targets can be associated either to the same or separate
SRPs. Single SRP systems are generally recommended because they are easier to
manage and performance may be better when spreading workloads across all
available resources in the array. Also, please note that SRP count and configuration
need to be specified during the system ordering process.
Snapshot deltas will always be stored in the source volumes SRP. There is no
advantage to having nocopy linked targets in a separate SRP because writes to a
source volume will only create snapshot deltas and will not initiate a copy to target.
If opting for a separate SRP for copy mode linked targets, the target SRP must have
enough disks to support the expected capacity and performance requirements of the
target volumes.
EMC HYPERMAX OS Lo c a l Rep lic a tio n

13

TimeFinder SnapVX

A single snapshot can have both copy and nocopy linked targets. All linked targets
from a single snapshot do not need to be in the same SRP. Source volumes and
linked targets (copy and nocopy modes) can be moved between SRPs while
TimeFinder sessions are active; FAST will move allocations accordingly.

Restore Operations
Snapshots can be restored directly to the source volume(s) via the symsnapvx
restore command or via Unisphere for VMAX. The symsnapvx terminate
restored command will terminate the restored session only and will not break the
source-to-snapshot relationship. Restoring from a snapshot to source will not affect
the point-in-time of any other snapshots or linked targets.
Restoring from a linked target back to a source is functionally possible although it is
not done with a restore command. Instead, the user would take a snapshot of a
linked target, which will essentially create a cascaded scenario, discussed further in
the following section. The user could then use the original source volume as a linked
target to the cascaded snapshot. Cascaded snapshots are discussed further in the
following section.

Cascading Snapshots
Cascading refers to taking a snapshot of a linked target, and also to linking a target to
a snapshot of a linked target. All tracks on a target volume must be defined before a
snapshot can be taken of the target volume.
Figure 10 illustrates one example of cascaded SnapVX sessions.

Figure 10. Cascaded Snapshots

The cascading capabilities of SnapVX are very robust. However, it is important to

note that some historical reasons for cascading clone or snap sessions may not exist
with SnapVX.
Since point-in-time data for SnapVX snapshots is stored in the SRP and cannot be
directly accessed by the host, the point-in-time of the snapshot is always pristine,
14 EMC HYPERMAX OS Lo c a l Rep lic a tio n

TimeFinder SnapVX

and there is no need to make a Gold Copy clone to cascade from. Even if a target is
linked to the snapshot and written to, the point-in-time of the snapshot will not
change. This reduces the amount of full volume copies that are required in most use
cases making SnapVX very space efficient.
Furthermore, the defining mechanism allows reads to tracks that do not reside on the
target volume to be serviced directly from the SRP and not redirected to the source
volume as would be the case with traditional snaps or clones. This not only improves
performance of the read but also reduces the possibility of target reads affecting
performance of the source volume.
Cascaded SnapVX sessions are supported with the following considerations:

There is no limit on the amount of cascaded hops that

are allowed.

A snapshot of a linked target is only allowed once the

linked target is in either the defined or copied state.

A cascaded snapshot can only restore to a linked target

that is in copy mode and has fully copied.

The cascaded chain can be broken at any point by

unlinking the target from the snapshot with the
following rules:

A snapshot that has a linked target cannot be

terminated.

A linked target that has a cascaded snapshot must

be in copy mode and fully copied before it can be
unlinked2.

Note: This restriction has been removed in the HYPERMAX OS Q1 2016 Service
Release. Beginning with this version of HYPERMAX OS and going forward, users can
unlink nocopy targets that have dependent/cascaded snapshots.

Reserved Capacity
Reserved Capacity is a percentage of the SRP that can only be consumed by new host
writes. Existing and new snapshots will be affected if the Free Capacity of the SRP
falls below the set Reserved Capacity. The following commands can be used to view
and change the values:

symcfg list srp v

symconfigure -sid <sid> -cmd "set srp

<srp_name> resv_cap=<value>;" commit

Valid values for Reserved Capacity percentage are from 1% to 80%, and NONE.
As an example, if the reserved capacity on an SRP is set to 10% and the SRP becomes
90% full with volume allocations, snapshot deltas, and SRDF Delta Set Extension
allocations, then only new host writes can consume the last free 10% of the SRP.
When only Reserved Capacity is available in an SRP, a snapshot will fail at the next
attempt to create a new snapshot delta, and the snapshot will need to be terminated.
EMC HYPERMAX OS Lo c a l Rep lic a tio n 15

TimeFinder SnapVX

VP Snap and Clone Nocopy Emulation Mode sessions will also fail at the next write
that requires a source track to be copied to target.
Copy to targets will halt and will not be able to complete. This includes SnapVX
linked targets, Clone copy mode sessions, and TimeFinder Mirror BCVs. Copy will
resume if free space is made available in the SRP, or if the Reserved Capacity value is
lowered to a sufficient value.
The Reserved Capacity only affects the TimeFinder copy process. Host reads and
writes to the targets will still be possible.

Interoperability
TimeFinder SnapVX is interoperable with other HYPERMAX OS features under the
following conditions:
SRDF

Snapshots can be taken from R1 and R2 volumes in all SRDF

modes (SRDF/S, SRDF/A, and SRDF/Metro)

Write-pacing is not required when taking snapshots from

SRDF/A R2 volumes

Linked targets in copy mode can be SRDF source volumes

Allocations owned by a source volume will be managed by

the Service Level Objective of the source volumes Storage
Group

Allocations owned by a target volume will be managed by

the Service Level Objective of the target volumes Storage
Group

Snapshot deltas will be managed by the Optimized Service

Level Objective

Read miss I/Os to target tracks that are owned by the source
volume will increment the FAST metrics for the source
volume, not the target volume, and may contribute to the
extent being promoted

Source and target volumes can be moved across SRPs while

TimeFinder sessions are active

FAST

Zero Space Reclaim

Zero space reclaim is supported on SnapVX source and

target volumes.

Persistent Allocations
Persistent Allocations are tracks that are unaffected by a standard reclaim operation.
The user can mark and unmark tracks as persistent with the Solutions Enabler
symdev or symsg commands, and with Unisphere for VMAX.
16 EMC HYPERMAX OS Lo c a l Rep lic a tio n

TimeFinder SnapVX

The considerations for Persistent Allocations with SnapVX are as follows:

Snapshots can be taken of a volume that has Persistent Allocations. However,
restores from a snapshot will be blocked if the source volume has any Persistent
Allocations. The user will need to remove the Persistent Allocations from the entire
volume in order to allow the restore operation. Persistent Allocations can be reset on
the source volume once the restore session is terminated.
Volumes with persistent allocations cannot be used as linked targets. Likewise,
persistent allocations cannot be set on linked targets.

Storage Group Operations

SnapVX has the ability to perform operations on entire Storage Groups (SGs). This
reduces complexity by eliminating the need for users to create separate device files,
device groups or composite groups for replication. Those options are still available in
Solutions Enabler. The storage group option is the only option for SnapVX in
Unisphere for VMAX. This document will focus on the storage group option in the
following implementation section.
When creating snapshots with the symsnapvx establish command, the sg
switch is used to specify the source SG, and one snapshot of the same name will be
created for each volume in the SG. If for some reason a snapshot cannot be created
for one of the volumes in the SG, the entire operation will fail and no snapshots will
be created.
When linking target volumes to a snapshot with the symsnapvx link command, the
lnsg switch is used to specify the entire target SG to link. Similar to the establish
command, if any volume in the SG cannot be linked for some reason, the entire
operation will fail and no volumes will be linked. Unisphere for VMAX also has an
option that will create a new SG and appropriate volumes for the user, which will be
shown later.
In the case of cascaded storage groups, a symsnapvx command issued to a parent
storage group will be applied to all child storage groups.

Expanding Storage Groups with Active Snapshots

SnapVX is designed to replicate entire applications that are configured on volumes
contained in an entire SG. It is possible to add volumes to an SG that has active
snapshots. The new volumes will be included the next time a snapshot is taken.
However, the volumes will not be included in previously existing snapshots.
If an SG is restored from snapshots that do not include the new volumes, the SG will
be taken back to a point-in-time when the new volumes did not exist. Therefore,
these new volumes in the SG should not be presented to the application and will be
set to Not Ready. The volumes will remain Not Ready after the restored session is
terminated and the user will need to determine the best course of action to
reintroduce the new volumes to the SG. The volumes will automatically become
ready again if the user decides to restore from snapshots that include these volumes.
Similar action is taken for using SGs that have been expanded as linked
targets. If the SG that is being used as the linked target contains more
volumes than are included in the specified snapshot, the extra volumes
EMC HYPERMAX OS Lo c a l Rep lic a tio n

17

Implementing TimeFinder SnapVX

will be set to Not Ready and will not be included in the point-in-time image.
The user will need to determine the best course of action to remove or
reintroduce the extra volumes. And if the SG is linked to another snapshot
that contains all of the volumes in the SG, the volumes will automatically
be made ready and will be included in the session.

Implementing TimeFinder SnapVX

Creating Snapshots
$ symsnapvx -sid 67 -nop -sg snapsource establish -name hourlysnap -ttl -delta 2
Establish operation execution is in progress for the storage group snapsource.
Please wait...
Polling for Establish.............................................Started.
Polling for Establish.............................................Done.
Polling for Activate..............................................Started.
Polling for Activate..............................................Done.
Establish operation successfully executed for the storage group snapsource
Figure 11. Creating a snapshot called hourlysnap and keeping for 2 days

Figure 12. Creating a Snapshot with Unisphere Data Protection Wizard

Figure 13 shows there are 4 generations of snap from the storage group snapsouce,
and Figure 14 shows a more detailed view giving more information including the each
snapshot was taken and expiration date if one was set on creation.

18 EMC HYPERMAX OS Lo c a l Rep lic a tio n

Implementing TimeFinder SnapVX

$ symsnapvx -sid 67 list -sg snapsource

Storage Group (SG) Name
: snapsource
SG's Symmetrix ID
: 000197200067
(Microcode Version: 5977)
------------------------------------------------------------------------Sym
Num Flgs
Dev
Snapshot Name
Gens FLRG Last Snapshot Timestamp
----- -------------------------------- ---- ---- -----------------------00040 hourlysnap
4 .... Mon Oct 20 11:00:00 2014
00041 hourlysnap
4 .... Mon Oct 20 11:00:00 2014
00042 hourlysnap
4 .... Mon Oct 20 11:00:00 2014
00043 hourlysnap
4 .... Mon Oct 20 11:00:00 2014
Flgs:
(F)ailed
(L)ink
(R)estore
(G)CM

:
:
:
:

X
X
X
X

=
=
=
=

Failed, . = No Failure
Link Exists, . = No Link Exists
Restore Active, . = No Restore Active
GCM, . = Non-GCM

Figure 13. Listing of snapshots for storage group snapsource

$ symsnapvx -sid 67 list -sg snapsource detail
Storage Group (SG) Name
: snapsource
SG's Symmetrix ID
: 000197200067
(Microcode Version: 5977)
-----------------------------------------------------------------------------------------------------------------------Total
Sym
Flgs
Deltas
Non-Shared
Dev
Snapshot Name
Gen FLRG Snapshot Timestamp
(Tracks)
(Tracks)
Expiration Date
----- -------------------------------- ---- ---- ------------------------ ---------- ---------- -----------------------00040 hourlysnap
0 .... Mon Sep 29 11:00:00 2014
26371
25848
NA
hourlysnap
1 .... Mon Sep 29 10:00:00 2014
26389
25866
NA
hourlysnap
2 .... Mon Sep 29 09:00:00 2014
26389
5120 Thu Oct 23 10:13:55 2014
hourlysnap
3 .... Mon Sep 29 08:00:00 2014
26389
5120 Wed Oct 22 10:11:58 2014
00041 hourlysnap
0 .... Mon Sep 29 11:00:00 2014
26379
25886
NA
hourlysnap
1 .... Mon Sep 29 10:00:00 2014
26393
25900
NA
hourlysnap
2 .... Mon Sep 29 09:00:00 2014
26393
5086 Thu Oct 23 10:13:55 2014
hourlysnap
3 .... Mon Sep 29 08:00:00 2014
26393
5086 Wed Oct 22 10:11:58 2014
00042 hourlysnap
0 .... Mon Sep 29 11:00:00 2014
26377
25833
NA
hourlysnap
1 .... Mon Sep 29 10:00:00 2014
26388
25844
NA
hourlysnap
2 .... Mon Sep 29 09:00:00 2014
26388
5199 Thu Oct 23 10:13:55 2014
hourlysnap
3 .... Mon Sep 29 08:00:00 2014
26388
5199 Wed Oct 22 10:11:58 2014
00043 hourlysnap
0 .... Mon Sep 29 11:00:00 2014
26377
25857
NA
hourlysnap
1 .... Mon Sep 29 10:00:00 2014
26386
25866
NA
hourlysnap
2 .... Mon Sep 29 09:00:00 2014
26386
5137 Thu Oct 23 10:13:55 2014
hourlysnap
3 .... Mon Sep 29 08:00:00 2014
26386
5137 Wed Oct 22 10:11:58 2014
---------- ---------422172
247984
Flgs:
(F)ailed : X = Failed, . = No Failure
(L)ink
: X = Link Exists, . = No Link Exists
(R)estore : X = Restore Active, . = No Restore Active
(G)CM
: X = GCM, . = Non-GCM

Figure 14. Listing of snapshots for storage group snapsource with detail option

Note: See Appendix B for information on the GCM Flag

EMC HYPERMAX OS Lo c a l Rep lic a tio n

19

Implementing TimeFinder SnapVX

Figure 15. Viewing Snapshots from Unisphere for VMAX

Linking, relinking, unlinking

To access a point in time copy, a host mapped target volume is linked to the
snapshot data. The links may be created in Copy mode for a permanent copy of the
target volume, or in Nocopy mode for temporary use.
Copy mode links create full-volume clones of the data. Nocopy mode links are space
saving snapshots that only consume space when host data is written directly to the
target volume. Both modes are allowed to be in either the same or separate SRP as
the source volume.
$ symsnapvx -sid 67 -sg snapsource -snapshot_name hourlysnap -gen 2 link -lnsg snaptarget
Execute Link operation for Storage Group snapsource (y/[n]) ? y
Link operation execution is in progress for the storage group snapsource. Please wait...
Polling for Link..................................................Started.
Polling for Link..................................................Done.
Link operation successfully executed for the storage group snapsource
Figure 16. Solutions Enabler Link Operation

Figure 16 shows the cli commands for linking to a snapshot, note that a generation
number was specified. If no generation is specified the most recent snapshot for the
snapshot name provided will automatically be selected.
Note: Please see Appendix C for information on monitoring the copy process to copy
mode linked targets.
When linking snapshots via Unisphere for VMAX, the user is presented with existing
SGs to select for the targets. Unisphere for VMAX can also create a new SG with the
appropriate volumes and perform the link operation from one simple wizard, as seen
in Figure 17.

20 EMC HYPERMAX OS Lo c a l Rep lic a tio n

Implementing TimeFinder SnapVX

Figure 17. Unisphere for VMAX Link Wizard

Should the user need to transition to a different snapshot copy using the same set of
source and target volumes a relink operation can be performed linking to a different
snapshot or a different generation of the same snapshot. Users should unmount any
target volumes from the mount host and remount after relink to ensure that the data
the host sees is correct Figure 18 shows the relink process from the CLI and Figure 19
shows the relink process the Unisphere GUI.

$ symsnapvx -sid 67 -sg snapsource -snapshot_name hourlysnap -gen 0 relink -lnsg snaptarget
Execute Relink operation for Storage Group snapsource (y/[n]) ? y
Relink operation execution is in progress for the storage group snapsource. Please wait...
Polling for Relink..................................................Started.
Polling for Relink..................................................Done.
Relink operation successfully executed for the storage group snapsource
Figure 18. Relinking via command line

EMC HYPERMAX OS Lo c a l Rep lic a tio n

21

Implementing TimeFinder SnapVX

Figure 19. Relinking a target snapshot to a different point in time Unisphere for VMAX

HYPERMAX OS supports up to 1,024 linked targets per source volume.

At any time the target volume can be unlinked from the snap copy, if the link was
created with the copy mode and state transitioned to a copied state the target
volumes will be an independent copy of the source.
Independent copies that are no longer required can be reused as linked targets in the
future providing there are no snapshots cascaded off these volumes. If the space
used by linked copies needs to be returned to the SRP the user can run the symdev
free all command to return this space to the system for global use. Please note
that the symdev free all command provides the user with the ability to wipe a
volume of all data and should be used with caution and only by knowledgeable
administrators.

Restoring from snapshots

It is possible to restore from any point in time snapshot that is available in the array.
Figure 20 shows how to restore from a snapshot to the production volume using the
CLI commands. It is recommended to unmount the production volume prior to
issuing the restore operation and remount after to ensure that the host sees the
22 EMC HYPERMAX OS Lo c a l Rep lic a tio n

Emulation Support for TimeFinder Mirror, Clone, and VP Snap

correct data. Users can determine which snapshot to use by verifying the data
through a linked target with the link/relink commands.
$ symsnapvx -sid 67 -sg snapsource -snapshot_name hourlysnap -gen 2 restore
Execute Restore operation for Storage Group snapsource (y/[n]) ? y
Restore operation execution is in progress for the storage group snapsource. Please wait...
Polling for Restore..................................................Started.
Polling for Restore..................................................Done.
Restore operation successfully executed for the storage group snapsource
Figure 20. Restoring from snapshot

Figure 20 shows the command line option restoring from generation 2 of a snapshot
to the source volume.

Emulation Support for TimeFinder Mirror, Clone,

and VP Snap
SnapVX provides emulation modes for TimeFinder Mirror, Clone, and VP Snap. This
allows the user to issue legacy TimeFinder commands when in reality SnapVX
sessions are created in the background. The sessions will appear to be legacy
TimeFinder sessions to the user. A single source volume cannot have both SnapVX
and Emulation sessions at the same time.
Solutions Enabler and Unisphere for VMAX steps to create sessions are exactly the
same as in the latest versions of Enginuity 5876, and the sessions will follow all
feature restrictions from Enginuity 5876, including session counts, cascaded hop
limits, and requiring source-target pairing. Emulation sessions cannot take
advantage of Storage Group operations ( sg option). Emulation sessions will copy
data directly from source to target without using snapshot deltas.
Emulation mode target volumes can be moved between SRPs while sessions are
active.

TimeFinder VP Snap Emulation

VP Snap control commands at 5977 are exactly the same as 5876, enabling users to
use their existing VMAX VP Snap scripts on HYPERMAX OS. However, there are
several behavioral differences that need to be understood when preparing volumes
and monitoring sessions. The following behaviors apply to VP Snap in HYPERMAX
OS:

All VP Snap target volumes from a specific source do not need to be

associated to the same SRP.

VP Snap target volumes can be moved across SRPs while sessions are
active. Non-shared allocations will be moved.

EMC HYPERMAX OS Lo c a l Rep lic a tio n

23

Conclusion

As source tracks are updated, the Protected Track counts will not
decrement.

As source tracks are updated when the session is active, the preserved
point-in-time tracks for the VP Snap emulation sessions will be stored
in the SRP of the source volume, even if the target volume is in a
different SRP. Only changed tracks on the target volume are stored in
the target SRP.

Shared allocation counts in Solution Enabler and Unisphere for VMAX

do not apply due to the way that shared allocations are handled in
HYPERMAX OS. These counters will always show zero.

VP Snap target volumes will not be deallocated when the sessions are
terminated. If the target volume is in a separate SRP from the source
volume, any allocations that reside in the source SRP after terminate
will be relocated to the target SRP by a FAST compliance move.

Note: Please see Appendix C for information on monitoring the copy process of Mirror
and Clone emulation sessions.

TimeFinder Snap Deprecation

TimeFinder Snap is not available with HYPERMAX OS for open systems.
EMC offers services for TimeFinder Snap users that would like help
converting to SnapVX on HYPERMAX OS. Please contact your local account
team for more information.

Conclusion
TimeFinder SnapVX provides new functionality and combines the benefits of the
TimeFinder Clone, Mirror, and VP Snap into one easy-to-use software feature.
SnapVX allows the user to create snapshots without the need for a target volume.
Snapshots can then be used to link to target volumes in either full-copy or nocopy
mode which can then be presented to the host server. SnapVX allows for far greater
scalability than previous TimeFinder offerings, with up to 256 snapshots per source
volume and 1024 linked target volumes per source volume. SnapVX also introduces
the ability to take snapshots on a Storage Group level, and uses advanced redirecton-write technology.
SnapVX is compatible with many other HYPERMAX OS features. And along with all of
the new functionality that is provided, users can also run emulation of TimeFinder
Mirror, Clone, and VP Snap which will use SnapVX technology in the background,
completely transparent to the user until they are ready to make the switch and take
full advantage of SnapVX.

24 EMC HYPERMAX OS Lo c a l Rep lic a tio n

References

References
Reference information and product documentation can be found at support.EMC.com
including;
EMC VMAX All Flash Product Guide for VMAX 450F,
450FX , 850F, 850FX with HYPERMAX OS
EMC VMAX3 Family with HYPERMAX OS Product Guide
EMC Solutions Enabler TimeFinder SnapVX CLI User
Guide
EMC Solutions Enabler TimeFinder Family CLI User Guide
EMC VMAX3 Family Feature Overview
EMC VMAX3 Service Level Provisioning with Fully
Automated Storage Tiering (FAST)

EMC HYPERMAX OS Lo c a l Rep lic a tio n

25

Appendices

Appendices
Appendix A
TimeFinder SnapVX State Table
The following table describes prerequisites, transient states, and final states for all
controls:
Action

Prerequisite

Transient State

Final State

Establish

None

Establish In Progress

Established

Restore

Established

Restore In Progress

Restored

If the source device is a link

target, must be fully copied.

Terminate

Established

Terminate In Progress

NA

Terminate with
FLAG1_RESTORED

Restored

NA

NA

Setmode Copy

Linked NoCopy

Link Copy In Progress

Link Copied

Setmode NoCopy

Link Copy In Progress or Link

Copied

NA

Linked

Set TTL

Established with no links or

restores.

NA

NA

Link

Established

NA

Linked

Link with FLAG1_COPY

Established

Link Copy In Progress

Link Copied

Unlink

Linked or

NA

NA

NA

Linked

Link Copy In Progress

Link Copied

NA

NA

Link Copied
If the target is the source of
another snapshot, the link
must be fully copied.
Relink

Linked or
Link Copied

Relink with
FLAG1_COPY

Linked or

Rename

Established

Link Copied

26 EMC HYPERMAX OS Lo c a l Rep lic a tio n

Appendices

Appendix B
Geometry Compatibility Mode (GCM)
An array running HYPERMAX OS cannot create a device that is exactly the same size
as a device with an odd number of cylinders on an array running Enginuity 5876. In
order to support the full functionality, SRDF requires that R1 and R2 devices in a
device pair be same size and TimeFinder requires that source and target devices are
the same size.
HYPERMAX OS introduces a new device attribute, Geometry Compatible Mode (GCM).
A device with GCM set is treated as half a cylinder smaller than its true configured
size so the device will be treated as the same size as an Enginuity 5876 device with
an odd number of cylinders, thus enabling full functionality between HYPERMAX OS
and Enginuity 5876 for SRDF, TimeFinder SnapVX, and TimeFinder emulations, and
ORS.
The GCM attribute can only be set for devices on arrays running HYPERMAX OS. The
attribute can be set manually or automatically as part of an operation that creates a
local or remote replication relationship.

The symdev set /unset, symdg set/unset, symcg set/unset, and symsg
set/unset commands have been enhanced with a new option -gcm to set and
unset GCM for a device or group.

The symdev show, symdev list v, symdg show ld, symdg list ld v,
sympd show, and sympd list v commands have been enhanced to report the
GCM attribute.

The symrdf createpair command has been enhanced to transparently set/unset

the GCM attribute as part of the create pair operation, as follows:
o

Set the GCM attribute for a target device that is configured a cylinder larger.
The source of the copy can be:

A device on an array running Enginuity 5876 with an odd number of

cylinders and capacity that matches the GCM size of the device.

A GCM device on an array running HYPERMAX OS.

Unset the GCM attribute for a target device that is configured the exact same
size as the source of the copy. The source of the copy can be:

A device on an array running Enginuity 5876 with even number of the

cylinders and capacity that matches the size of the device on the array
running HYPERMAX OS.

A device on the array running HYPERMAX OS without the GCM attribute.

ORS
o

The ORS create operation will be modified to use the GCM size when
establishing a push or pull session to the remote target.
EMC HYPERMAX OS Lo c a l Rep lic a tio n

27

Appendices

TimeFinder SnapVX
o

If a SnapVX snapshot is created from a GCM device, then the resulting

snapshot will also be given the GCM attribute and this will be reported as an
attribute of the snapshot.

A SnapVX link operation will change the GCM attribute on the link target
device to match the GCM setting of the snapshot.

TimeFinder Clone and VP Snap

o

Create, full establish, or full restore operations between a GCM device and a
non-GCM device will result in the device that is the target of the data copy
having its GCM attribute changed to match the GCM attribute setting of the
device that is the source of the data copy.

When the source and target devices are the same physical size, and the
source of a clone session is a GCM device and the target device is not, then
the Clone to Larger Target rules will be enforced.

TimeFinder Mirror
o

Full establish and full restore operations between a GCM device and a nonGCM device will result in the device that is the target of the data copy having
its GCM attribute changed to match the GCM attribute setting of the device
that is the source of the data copy.

Appendix C
Monitoring the Copy Process
When monitoring the copy process to a full copy linked target, the number of tracks
remaining to copy are determined by a sum of multiple internal counters, capped at
the maximum size of the volume. If the sum of these values exceeds the size of the
device, then it may appear that the copy has not started or is stuck when querying the
session from Solutions Enabler or Unisphere for VMAX, even though the copy has
actually begun. See Figure 21 as an example.
$ symsnapvx -sid 067 list -sg snapsource -linked -detail
Storage Group (SGName
: SNVX_SG
SG's Symmetrix ID
: 000197200067
(Microcode Version: 5977)
----------------------------------------------------------------------------------------------Sym
Link Flgs
Remaining Done
Dev
Snapshot Name
Gen Dev
FCMD Snapshot Timestamp
(Tracks)
(%)
----- -------------------------------- ---- ----- ---- ------------------------ ---------- ---00040 hourlysnap
2 0003D ...I Mon Sep 29 14:01:59 2014
18510
0
00041 hourlysnap
2 0003E ...I Mon Sep 29 14:01:59 2014
18510
0
00042 hourlysnap
2 0003F ...I Mon Sep 29 14:01:59 2014
18510
0
00043 hourlysnap
2 00040 ...I Mon Sep 29 14:01:59 2014
18510
0
---------74040
Flgs:
(F)ailed
: F = Force Failed, X = Failed, . = No Failure
(C)opy
: I = CopyInProg, C = Copied, D = Copied/Destaged, . = NoCopy Link
(M)odified : X = Modified Target Data, . = Not Modified
(D)efined : X = All Tracks Defined, . = Define in progress
Figure 21. Viewing snapshot with linked targets
28 EMC HYPERMAX OS Lo c a l Rep lic a tio n

Appendices

The user may be able to notice usage increase on the target volumes or SRPs. This
does not slow down the actual copy, just the way that the copy is reported. Once the
internal counters drop below a certain threshold the number of tracks reported to the
user will drop dramatically.
Another effect of this is that incremental relink operations may appear as full
operations because the internal counters add up to the full size of the volume. Both
of these behaviors will be more noticeable on larger volumes.
This behavior also applies to monitoring the copy process of TimeFinder Mirror and
Clone emulation sessions, which use SnapVX in the background.
This behavior is also documented in knowledgebase solution 196700.

Appendix D
Nocopy Linked Target Functionality
Beginning with the HYPERMAX OS Q1 2016 Service Release, users can continue to
access the data on fully-defined nocopy targets after they have 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/snapshot deltas.
When a target is unlinked, the shared remains in place. In other words, unlinking will
not unshare the allocations. Even after unlinked, termination of a snapshot will
result in the target owning the snapshot delta. And an updated write to the source
track will result in the target owning the original track. Target will also take ownership
of any shared source tracks if the source is deallocated after unlink.
This enhanced functionality allows the user to continue to access the target data after
unlink in the same way that previously required full copy targets, but without
duplicating the entire backend data from the point-in-time to the target.
There are a few important aspects to understand about this behavior:

Nocopy target data will only be valid if the target is fully defined before unlink.
The following commands will help the user determine if defined process has
completed on target(s):
o symsnapvx <sourcedevs> snapshot_name list linked
o symsnapvx -<targetdevs> -snapshot_name verify
-linked -defined -by_tgt

If the user wants to deallocate the data on the target(s) after unlink, they can
do so by issuing the symdev free all command to the target volume.
Please note that this is a powerful command that will completely deallocate
all data on the volumes that it is issued to. Extreme care must be taken when
using this command. As a safety mechanism, the free all command requires
the device to be not ready or unmapped.
EMC HYPERMAX OS Lo c a l Rep lic a tio n 29

Appendices

Similarly, after terminating a snapshot, users may not see as much capacity
as they expected freed up in the SRP 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/snapshot,

the data will be 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 the
HYPERMAX OS Q1 2016 Service Release.
This means that at earlier versions of HYPERMAX OS, users may observe the
behavior described in the previous bullets. But they should not rely on the
data on the targets after unlink.

In regards to performance, this feature should be considered to perform as

well as accessing linked nocopy targets.

Copyright 2016 EMC Corporation. All rights reserved. Published in the USA.
Published March, 2016
EMC believes the information in this publication is accurate as of its
publication date. The information is subject to change without notice.
The information in this publication is provided as is. EMC Corporation makes no
representations or warranties of any kind with respect to the information in this
publication, and specifically disclaims implied warranties of merchantability or
fitness for a particular purpose. Use, copying, and distribution of any EMC
software described in this publication requires an applicable software license.
EMC2, EMC, and the EMC logo are registered trademarks or trademarks of EMC
Corporation in the United States and other countries.
All other trademarks used herein are the property of their respective owners.
For the most up-to-date regulatory document for your product line, go to EMC
Online Support (https://support.emc.com).
30 EMC HYPERMAX OS Lo c a l Rep lic a tio n