====== SVC dedup pool ======

//Remember:// 

This garbage-collection process then requires a certain amount of free space to work efficiently. For this reason it is recommended to keep approximately **15% free space** in a DRP pool.

**Note:** Where possible limit the maximum transfer size sent to the IBM FlashSystem to no more than 256 KiB. This limitation is general best practice and not specific to only DRP. Based on perf issue, IBM recommend to use 64kB IO, for volumes with dedup^and compression.

===== Reclaiming space in a data reduction pool =====

https://www.ibm.com/support/pages/handling-out-physical-space-conditions

Due to the basic organization of a data reduction pool, extent level migrations are generally not possible. However, data reduction pools make full use of the SCSI Unmap functionality including a garbage collection process that can be used to reclaim space. Because of this capability, there are a few different methods that can be used to reclaim space. If the out of space storage is in a data reduction pool, it is recommended to contact IBM Support.

Strategies to address the situation generally include:

  * Create fully allocated, sequential, volumes to consume the capacity mdisks in the pool.
      * Fully allocated volumes in a Data Reduction Pool will reserve extents in the data volume, but do not write to the mdisks. This makes Garbage Collection to increase its priority to reclaim garbage extents and send unmaps to the back-end while reducing the reclaimable capacity.
      * Use host trim commands to get an accurate accounting of the free space of the volumes in the pool and to accurately report the reclaimable space.
  * Consider migrating volumes to another pool using volume mirroring to move data out of the affected pool.
  * If alternate storage can be found to replace an mdisk, it is also possible to make fully allocated volumes to reserve all the mdisk extents on the out of space system. Once this step is done, it is possible to use rmmdisk -force to force a mdisk to migrate all of its data onto other available storage in the pool and eventually remove one or more mdisks from the pool.
      * The rmmdisk command does not allow you to specify the target mdisks for the migration tasks it creates. Because of this limitation, the step to create fully allocated, sequential, volumes to reserve all of the extents on the out of space controller is critical to success.

**Note** that all of these strategies require unlocking the write protected array or unlocking the array. As in a standard pool, it is recommended to power off all hosts accessing the pool in order to avoid host writes from impacting the success of the plan.

===== Considerations for compressing and deduplicating back-end =====

The IBM FlashSystem detects:
  * If the MDisk is thin-provisioned.
  * The total physical capacity of the MDisk.
  * The used and remaining physical capacity of the MDisk.
  * Whether unmap commands are supported by the back-end. By sending SCSI unmap commands to thin-provisioned MDisks, the system marks data that is no longer in use. Then, the garbage-collection processes on the back-end can free unused capacity and reallocate it to free space.
  * 
Using an appropriate compression and or data deduplication ratio is key to achieving a stable environment. If you are not sure about the real compression or data deduplication ratio, contact your IBM technical sales representative to obtain more information.

The nominal capacity from a compression and deduplication enabled storage system is not fixed and it varies based on the nature of the data. Always use a conservative data reduction ratio for the initial configuration.
Using the suitable ratio for capacity assignment can cause an out of space situation. If the MDisks do not provide enough capacity, IBM FlashSystem disables access to all the volumes in the storage pool