Deduplication enables you to save space in vFiler units by eliminating redundant data blocks within the vFiler units. You can run deduplication commands from both default and nondefault vFiler unit contexts.
Deduplication is used on redundant data only on the FlexVol volumes owned by a vFiler unit (this is called FlexVol volume granularity). Currently, deduplication is supported at the FlexVol volume level. It is not supported at the qtree level, although a vFiler unit can own volumes and qtrees.
Storage owned by a vFiler unit is not accessible by any other vFiler unit by using deduplication commands. From the default vFiler unit, you can execute deduplication commands on volumes owned by any vFiler unit in the storage system. From a nondefault vFiler unit's context, you cannot execute any deduplication command on a FlexVol volume that is not owned by the current vFiler unit.
You can have a maximum of eight deduplication sessions, which is also the default limit. The minimum deduplication session limit is one. The hosting storage system allows a maximum of eight concurrent deduplication operations and they are shared among all hosted vFiler units. However, on a 32-bit platform, the maximum number of concurrent deduplication operations per storage system is five.
During a vFiler unit offline or online migration, deduplicated volumes in the vFiler unit are also migrated. The FlexVol volumes on the destination vFiler unit inherit the deduplication attributes of the source vFiler unit.
However, if there is a situation in which the source storage system is down and the destination storage system becomes the new source storage system, you must enable deduplication to continue. The best practice is to have deduplication enabled on both locations.
For more information about deduplication, see the Data ONTAP Storage Management Guide for 7-Mode.