A decision framework for pool type

Why this matters in production

Pool type is a one-way door at scale: changing it means migrating every object. A short, ordered framework produces a defensible answer in minutes and makes the reasoning reviewable afterwards.

The five questions

1. What is the write size distribution?

Small writes (under k × min_alloc_size, so under about 16 KiB for a typical 4+2) → replication. This question alone settles most cases.

2. Is the data modified in place after writing?

Frequent in-place modification → replication. Write-once or append-only → EC remains viable.

3. What is the latency requirement?

A p99 budget in single-digit milliseconds → replication. Tens of milliseconds or more → EC is fine.

4. How large is it, relatively?

If the workload is a small fraction of cluster capacity, the EC saving is not worth the complexity or the risk. Save EC for the workloads where the saving is material.

5. Does the cluster support the profile?

Enough failure domains for k+m with headroom, cluster network sized for k× recovery traffic, CPU headroom for decode. If not, the profile is not available regardless of workload fit.

The decision path

graph TD
    A[Workload] --> B{Writes under 16 KiB?}
    B -->|yes| R[Replication]
    B -->|no| C{Modified in place?}
    C -->|frequently| R
    C -->|rarely or never| D{p99 budget under 10ms?}
    D -->|yes| R
    D -->|no| E{Material share of capacity?}
    E -->|no| R
    E -->|yes| F{Cluster supports the profile?}
    F -->|no| R
    F -->|yes| G[Erasure coding]

The default at every unclear branch is replication. That asymmetry is deliberate: the cost of wrongly choosing replication is capacity, and the cost of wrongly choosing EC is a migration.

Worked examples

Splitting mixed workloads

Most real platforms are not one workload. When the questions give different answers to different parts — live data versus backups, hot versus cold partitions — split them across pools rather than compromising on one type for everything.

Quiz

Production discipline

Run the framework at design time and record the decisive question in the pool documentation. Re-run it when the cluster changes shape or the workload’s access pattern shifts materially — pool type cannot be changed in place, but knowing a placement has become suboptimal lets you plan a migration deliberately rather than discover the mismatch during an incident.

Cross-course references

• Kubernetes: an ordered decision procedure for StorageClass selection serves the same purpose
• Linux: RAID level selection guides follow the same shape of ordered, cheapest-first questions