Your Browser is Out of Date

Nytro.ai uses technology that works best in other browsers.
For a full experience use one of the browsers below
Dell EMC PowerMax and VMAX All Flash: TimeFinder SnapVX Local Replication
Executive summary Introduction TimeFinder SnapVX overview
Creating snapshots
Generation numbers
Time-to-live value
Host writes to source
Redirect-on-write
Replication cache
Shared allocations
Linking target volumes to snapshots
Relinking
Unlinking
Defining state
Linking a larger target
Source-volume or linked-target SRP relationships
Restore operations
Cascading snapshots
Reserved capacity
Interoperability
Storage group operations
Secure snaps
Online device expansion
Role Based Access Controls
Implementing TimeFinder SnapVX PowerMaxOS Q3 2020 release enhancements TimeFinder legacy modes: Mirror, Clone, and VP Snap Conclusion Appendix A: TimeFinder SnapVX state table Appendix B: Geometry compatibility mode Appendix C: Monitoring the copy process Appendix D: Nocopy Linked Target behavior before HYPERMAX OS 5977.810.184 Appendix E: Scheduling snapshots with Unisphere for PowerMax Appendix F: System resource planning for capacity and performance Appendix G: Technical support and resources

Shared allocations

Home > Storage > PowerMax and VMAX > Data Protection > Dell EMC PowerMax and VMAX All Flash: TimeFinder SnapVX Local Replication > Shared allocations

Shared allocations

  • VP Snap in Enginuity 5876 introduced back-end allocation sharing between VP Snap target volumes; multiple snapshots from a source volume can share point-in-time versions of a track. A back-end 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.

    SnapVX in HYPERMAX OS 5977 greatly enhanced 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 number of volumes that can share an allocation.

    Sharing of a snapshot delta between snapshots is like that of VP Snap in Enginuity 5876; when a source write arrives and the original track needs to be preserved as a snapshot delta for multiple snapshots, only a single snapshot delta needs creating.

    However, nocopy-linked targets begin to share tracks with the source volume or share snapshot deltas for the specific point-in-time as part of the define process. The targets are 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 is preserved as a snapshot delta and continues to be shared with the target or targets.

    Writes to a target are applied only to the specific target. If the write is to a track that is being shared then the track for the specific target is split from the shared group, and any other snapshots or targets continue to share the original shared track.

    Reporting of shared track counts on pools or SRPs by Solutions Enabler or Unisphere is not applicable in HYPERMAX OS 5977. However, some Solutions Enabler displays report shared track counts on pools for backwards compatibility with older arrays.

    Solutions Enabler instances and Unisphere report the non-shared track count on each snapshot. The non-shared count is the most important value because non-shared snapshot deltas are discarded when the snapshot is terminated, which frees space in the SRP.

    Note: See Appendix D: Nocopy Linked Target behavior before HYPERMAX OS 5977.810.184 for for changes to the nocopy target functionality introduced in HYPERMAX OS 5977.810.184.