storage:svc_dedup
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
storage:svc_dedup [2022/08/09 13:58] manu |
storage:svc_dedup [2022/08/09 14:03] (current) manu |
||
|---|---|---|---|
| Line 7: | Line 7: | ||
| **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. | **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** | + | ===== 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. | 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. | ||
| Line 22: | Line 24: | ||
| **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. | **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 | ||
storage/svc_dedup.1660046317.txt.gz · Last modified: 2022/08/09 13:58 by manu
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3
