Table 4-14 IBM FlashSystem 9100 and external storage best practices  Front End External Storage  Recommendations IBM FlashSystem 9100:  DRP above simple RAID Storwize 5000 or any  other fully allocated  volumes  Yes GLYPH<SM590000> Use DRP at the top level to  plan for deduplication and  snapshot optimizations. GLYPH<SM590000> DRP at the top level provides  the best application capacity  reporting (volume written  capacity). GLYPH<SM590000> Always use compression in  DRP to get the best  performance. GLYPH<SM590000> Bottlenecks in compression  performance come from  metadata resource use, not  compression processing. IBM FlashSystem 9100:  fully allocated IBM FlashSystem A9000 Use with care GLYPH<SM590000> Need to track physical capacity  use carefully to avoid  out-of-space issues. GLYPH<SM590000> SVC can report physical use  but does not manage to avoid  the out-of-space state.  GLYPH<SM590000> No visibility of each  application’s use at the SVC  layer. GLYPH<SM590000> If actual out-of-space happens,  there is very limited ability to  recover. Consider creating a  sacrificial emergency space  volume. IBM FlashSystem 9100:  fully allocated above  multitier data, reducing  back end  IBM FlashSystem A9000 and IBM Storwize 5000  with DRP Use with great care GLYPH<SM590000> Easy Tier is unaware of the  physical capacity in the tiers of  the hybrid pool. GLYPH<SM590000> Easy Tier tends to fill the top  tier with the “hottest” data. GLYPH<SM590000> Changes in compressibility of  data in the top tier can  overcommit the storage,  leading to out-of-space. IBM FlashSystem 9100:  DRP above data, reducing  back end IBM FlashSystem 900  AE3  Yes GLYPH<SM590000> Assume 1:1 compression in  back-end storage: do not  overcommit. GLYPH<SM590000> Small extra savings can be  realised from compressing  metadata. 114  IBM FlashSystem 9100 Architecture, Performance, and Implementation