A capacity planner notices that free space on an AHV cluster grows after EC-X is enabled on a container. They need a defensible runway forecast for the next quarter. Which consideration must be included?
Select an answer to reveal the explanation.
Short Explanation
Think of EC-X like trading a bigger gas tank for a heavier engine: it can stretch your capacity, but rebuilds and I/O overhead still matter. If you forecast runway by only watching free space, you'll miss the performance cost. Always check both capacity savings and rebuild behavior before you call the forecast safe.
Full Explanation
EC-X is a capacity-efficiency capability that uses erasure coding to reduce the storage footprint of eligible data. For capacity forecasting, the key is not only that used capacity may drop, but also that erasure coding can increase rebuild work and add CPU, latency, or I/O overhead during failures and re-protection. A defensible runway forecast therefore treats EC-X as a trade-off: better capacity utilization, but potentially slower rebuilds and different performance headroom. EC-X is not a simple protection downgrade to a single copy; it still provides redundancy through coded protection, so forecasts should not assume shorter rebuilds or lower protection. It is also not limited to snapshot metadata or small bookkeeping savings; it affects data placement and rebuild behavior, so ignoring rebuild, CPU, or latency impact is wrong. EC-X does not guarantee linear savings for every dataset, because savings depend on data characteristics, configuration, and workload access patterns, so runway models must be validated against observed cluster metrics. Exam caveat: choose the answer that pairs capacity efficiency with rebuild and performance considerations. Operational check: review EC-X-enabled container settings and current cluster performance, then compare capacity runway before and after enabling EC-X using observed usage, rebuild behavior, and latency trends.