Resizing RBD images, up and down

Why this matters in production

Growing is a two-part operation — the image and then the filesystem — and stopping halfway leaves capacity that exists and is unusable. Shrinking is genuinely dangerous, and the safe procedure is the reverse order with an additional step people skip.

Growing

rbd resize --size 200G rbd-vms/vm-disk-01
rbd info rbd-vms/vm-disk-01 | grep size

The image is now larger. The filesystem inside it is not. The client must be told:

Kernel RBD:

# the block device usually picks up the new size automatically
blockdev --getsize64 /dev/rbd0

# extend the filesystem
xfs_growfs /mnt/data           # XFS
resize2fs /dev/rbd0            # ext4

librbd under QEMU:

# the domain using the image, from virsh list --all
DOMAIN=vm-db-01

virsh blockresize "$DOMAIN" --path vda --size 200G
# then, inside the guest:
xfs_growfs /

rbd-nbd:

rbd-nbd resize /dev/nbd0
xfs_growfs /mnt/data

Growth is online for both XFS and ext4 — no unmount needed.

Shrinking

rbd resize --size 50G --allow-shrink rbd-vms/vm-disk-01

The --allow-shrink flag exists because this discards everything beyond the new size, immediately and irreversibly. If the filesystem extends past that point, it is now corrupt.

The safe order is the reverse of growth, and the middle step is the one that gets skipped:

# 1. back up. this is not optional.
rbd snap create rbd-vms/vm-disk-01@pre-shrink

# 2. unmount and check the filesystem
umount /mnt/data
e2fsck -f /dev/rbd0

# 3. shrink the FILESYSTEM first, to comfortably less than the target
resize2fs /dev/rbd0 45G

# 4. only now shrink the image
rbd resize --size 50G --allow-shrink rbd-vms/vm-disk-01

# 5. remount and verify
mount /dev/rbd0 /mnt/data
df -h /mnt/data

XFS cannot be shrunk at all. An XFS volume that needs to be smaller requires creating a new smaller volume and copying the data.

In orchestrated environments

# Kubernetes: expand a PVC
spec:
  resources:
    requests:
      storage: 200Gi

With allowVolumeExpansion: true on the StorageClass, the CSI driver performs both the image resize and the filesystem extension. Shrinking is not supported, which is the correct default.

Quiz

Production discipline

Check rbd du before any shrink; thin provisioning means an over-provisioned image usually consumes only what it holds, and the reclamation is often unnecessary. Where a shrink is genuinely needed, make the snapshot and the filesystem-first ordering mandatory steps in the runbook, and treat XFS volumes as non-shrinkable.

Cross-course references

• Kubernetes: PVC expansion is supported and shrinking is not, for exactly these reasons
• Linux: LVM resize ordering follows the identical filesystem-first rule when shrinking