Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I am trying to determine the best approach for leveraging dedupe with iSCSI LUNs and SnapMirror. If SnapMirror were out of the equation, it sounds like the best approach to maximize deduplication is:
- Volume space guarantee = none (thin provisioned)
- LUN space reserved = no (thin provisioned)
- Volume autosize = on
- Snap autodelete = on
This would essentially "transfer" the space savings back to the aggregate for everyone to enjoy. However, the biggest problem I am seeing is that the volume autosize causes the SnapMirror replication to break all the time because the source volumes are growing larger while the destination volumes are not the same size or larger. This requires manual intervention, and many hours or days of SnapMirror being down. If I turn volume autosize off, I am now forced to create an unusually large volume to be able to hold the "worst-case scenario" of snapshots (user-created + SnapManager-created + SnapMirror-created). Is there another way to simultaneously achieve space savings with dedupe while keeping source and destination volumes sized equally for SnapMirror to keep humming along?
Thanks,
Bill
1 REPLY 1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
create destination volume with very big size but set guarantee=none, so essentially once you establish SM relationship on destination only the blocks which are physical written will be in use and rest free blocks will be in the aggregate.
