A capacity-oriented workload on a six-node Nutanix cluster stores mostly write-cold data that is written once and rarely overwritten. The container uses RF2, and spare capacity is limited. Which container setting best improves usable capacity while respecting write behavior?

Erasure coding (EC-X) is a container setting that converts write-cold data from full replicas into data and parity strips. Curator applies it in the background to extents that haven't been overwritten recently, so it suits exactly this workload: data written once and rarely changed. AOS chooses the strip size from the cluster size and the container's fault tolerance, for example 4/1 for RF2, and the recommendation is at least one more node than the strip width, which a six-node cluster satisfies. A 4/1 strip stores data at about 1.25x instead of RF2's 2x, recovering a large share of capacity while keeping the same one-failure tolerance. Because only cold data is encoded, new writes still land as normal RF2 replicas, so write performance is unaffected. Staying on RF2 without EC-X keeps the simpler path but leaves the capacity savings on the table, which the stem says you need. Raising the container to RF3 adds a third copy, consuming more space, not less. Deduplication helps only when many blocks are identical, such as full-clone VDI or base images; it does not always beat EC-X and does little for unique data. Exam caveat: EC-X is wrong for data with frequent overwrites, and it never raises or lowers the container's failure tolerance. Operational check: after enabling EC-X, check the container's data-reduction ratio in Prism once Curator scans have run.