Skip to main content
NetApp Knowledge Base

SnapMirror storage efficiency configurations and behavior

  1. Last updated
  2. Save as PDF
Views:
5,985
Visibility:
Public
Votes:
3
Category:
snapmirror
Specialty:
dp
Last Updated:

Applies to

  • ONTAP 9
  • SnapMirror
  • SnapVault

Answer

SnapMirror type-XDP allows storage efficiency independence between source and destination volumes. While this allows for increased flexibility, certain combinations of storage efficiency settings can cause source volume storage efficiency savings to be lost during transfer.

This KB is specific to SnapMirror type-XDP relationships. SnapMirror type-DP relationships maintain source-side storage efficiency savings by design but cannot have independent storage efficiency configurations between source and destination volumes.

Key:

  • Deduplication (D)  - Inline or background / post-process
  • Adaptive Compression (Ca) - Inline or postprocess
  • Secondary Compression (Cs) - Inline or postprocess
  • Logical Transfer with Storage Efficiency (LRSE) - All source-side storage efficiency savings are maintained by SnapMirror
  • Logical Transfer (LRE) - All source-side storage efficiency savings are lost during transfer, but can be re-gained at the destination
Source Destination Result
D or No storage efficiency D or No additional storage efficiency Logical Transfer with Storage Efficiency (LRSE)
D, Ca or Cs D or No additional storage efficiency Logical Transfer with Storage Efficiency (LRSE)
D, Ca or Cs D, Ca or Cs Logical Transfer (LRE)
Any combination of storage efficiency Any storage efficiency including Ca or Cs Logical Transfer (LRE)
  • Any form of additional compression on a SnapMirror destination results in a non-storage efficient LRE transfer.
Data compaction
  • Data compaction has no impact on if LRSE or LRE are used by SnapMirror.
Source Destination Result
Data compaction enabled No data compaction Data compaction savings on source only
No data compaction Data compaction enabled Data compaction savings on destination only
Data compaction enabled Data compaction enabled Data compaction savings on both volumes*

*A SnapMirror destination will re-pack any compacted sub-4K chunks sent by the source. This may result in different (but similar) data compaction savings between source and destination volumes.

ONTAP 9.8 and Temperature Sensitive Storage Efficiency (TSSE)
  • Temperature Sensitive Storage Efficiency (TSSE) is enabled for new volumes on AFF platforms running ONTAP 9.8 and later.
  • There is an open issue where TSSE volumes fail to replicate to ONTAP 9.6 or earlier SnapMirror destinations with "Invalid data operation(Replication engine error)" or "Failed to start transfer. (Operation not supported)" see BUG 1384963(fixed in ONTAP 9.9.1) for more details. This issue does not occur with ONTAP 9.7 or later destinations.
  • If replicating from a TSSE volume to a destination in ONTAP 9.7 or earlier, compression savings will be lost over the network. SnapMirror will continue to maintain deduplication savings and will continue to report "Logical Transfer with Storage Efficiency" (LRSE).
  • TSSE is not compatible with FabricPool in ONTAP 9.8. If replicating from a TSSE SnapMirror source volume to a FabricPool SnapMirror destination, compressed blocks are decompressed at the destination before being tiered by FabricPool.
AFF-A400 and Hardware Offload Storage Efficiency
  • AFF-A400 platforms use a new compression algorithm known as lrzw1a, also known as Hardware Offload Storage Efficiency.
  • The lrzw1a compression algorithm is incompatible with ONTAP 9.6 and earlier.
  • Replicating from a volume hosted on an AFF-A400 using the lrzw1a compression algorithm to a SnapMirror destination running ONTAP 9.6 or earlier will result in an LRE transfer.
  • Upgrade the destination cluster to ONTAP 9.7 or later to allow SnapMIrror to switch to a storage-efficient LRSE transfer.
Extended compressed data
  • Extended compressed data is a combination of AFF or modern FAS platforms, ONTAP 9.5 or later, adaptive compression with application IO size 8K, and data compaction.
  • If a source volume uses Extended compressed data, the destination must be running ONTAP 9.5 or later for SnapMirror to maintain storage efficiency savings (LRSE), regardless of the destination's storage efficiency settings. If the destination is running ONTAP 9.4 or earlier, LRE will be used. For more details, see BUG 1277896.
  • Since extended compressed data includes adaptive compression, enabling on a SnapMirror destination volume will result in an LRE transfer.
Other storage efficiency technologies
  • Aggregate deduplication (Cross-volume deduplication): Aggregate deduplication savings (inline or background / post-process) on a SnapMirror source are not retained by SnapMirror transfers. This has no impact to if LRSE or LRE are used. SnapMirror destination clusters can use aggregate deduplication with type-DP SnapMirror destination volumes. This also has no impact on if LRSE or LRE are used.
Changing from LRE to LRSE
  • In ONTAP 9.3 and later, disabling all additional compression on a SnapMirror destination will allow transfers to switch from LRE to LRSE and start maintaining source-side storage efficiency savings. This is called Automatic LRE to LRSE.
  • Automatic LRE to LRSE takes two transfers to kick in after disabling compression at the destination.
  • Manual LRE to LRSE can also be attempted in ONTAP 9.3 and later using the -enable-storage-efficiency true option in a snapmirror update command.
LRE to LRSE conversion only works when compression types (adaptive or secondary) match between source and destination. If compression types are (or were) different, switching from LRE to LRSE is not possible. To achieve LRSE functionality, you must re-baseline to a new destination volume without additional compression enabled. To avoid a lengthy re-baseline, see the steps in  How to enable SnapMirror storage efficiency between volumes with different compression types.
  • Prior to ONTAP 9.3, switching from LRE to LRSE requires a re-baseline.

Additional Information