Flattening clones and managing the dependency graph

Why this matters in production

Flattening converts a cheap reference into an independent copy. It costs capacity and I/O proportional to what the clone had not yet written, and it is the only way out of a dependency graph that has become unmanageable — so it is worth doing deliberately rather than reactively.

Flattening

rbd info rbd-vms/web-01 | grep -E 'parent|overlap'
# parent: rbd-templates/ubuntu-2404@v1
# overlap: 40 GiB

rbd flatten rbd-vms/web-01
# Image flatten: 100% complete...done.

rbd info rbd-vms/web-01 | grep parent   # nothing — independent now

The overlap figure is the cost: that much data is copied from the parent into the clone, consuming that much additional capacity and generating that much I/O.

When to flatten

The default policy that works well: flatten clones once they exceed a defined age, on the reasoning that a clone still present after a week is a long-lived volume rather than an ephemeral one.

The cost at scale

# total flattening cost for all children of a template
for c in $(rbd children rbd-templates/ubuntu-2404@v1); do
  rbd info "$c" | awk '/overlap/{print $2, $3}'
done

Flattening 300 clones of a 40 GiB template can mean copying several terabytes and hours of cluster I/O. Stage it, throttle it, and run it outside peak periods.

deep-flatten

rbd info rbd-vms/web-01 | grep features
# features: layering, exclusive-lock, object-map, fast-diff, deep-flatten

Without deep-flatten, flattening a clone that has its own snapshots leaves those snapshots still depending on the parent — so the parent still cannot be removed. With it, the flatten covers the clone’s snapshots too and the dependency is genuinely broken.

This is why deep-flatten is in the default feature set and should stay there: without it, a clone with snapshots is a dependency you cannot clear without deleting the snapshots.

Keeping the graph manageable

rbd children rbd-templates/ubuntu-2404@v1
rbd snap ls rbd-templates/ubuntu-2404

Practices that keep template retirement possible:

• Record the template and version each volume was cloned from
• Flatten clones after a defined age, automatically
• Limit the number of live template versions
• Check rbd children before any template lifecycle change

Quiz

Production discipline

Flatten on a defined age policy rather than reactively, since the decision is irreversible and the capacity it consumes is permanent. Sum the overlaps and multiply by the replication factor before any bulk flatten — the raw-capacity figure is what determines whether the operation is safe on the current cluster.

Cross-course references

• Kubernetes: promoting a snapshot-backed PVC to a full volume is the same one-way conversion
• Linux: breaking an overlayfs lower layer by copying it up has identical semantics