Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

Linux filesystem expansion: follow the block device to the mounted filesystem

Last updated: 5 Oct 20267 min read
tutorial
AdvancedBy AITrove Editorial

A storage expansion can cross several layers: provider allocation, partition, encrypted mapping, logical volume, filesystem, mount, and application quota. The order and commands depend on the actual stack. XFS and ext4 have different growth tools and constraints; a filesystem cannot use space its underlying block device has not exposed. A successful provider resize therefore needs a before-and-after map at every layer, a backup or snapshot recovery plan, and an application write test. Avoid copying a device name from a generic runbook: device ordering can change across boots, and growing the wrong layer may leave the intended mount unchanged.

Operational decision

A report service runs on a 164 GiB encrypted logical volume and needs another 87 GiB. The operator records the provider volume ID, stable device identifier, partition table, LUKS mapper, logical-volume extent map, filesystem type, and mount path. They increase the provider allocation in a disposable replica, rescan the block path through the supported platform procedure, then grow each applicable layer in order. After the filesystem-specific growth step, df reports the new capacity at the service mount, not merely at the raw device. The report service writes and reads a synthetic file, and a restore drill confirms that the previous backup still works. The production rollout uses one host cohort at a time.

bash
lsblk -f
findmnt /srv/reports
df -hT /srv/reports

Cost and verification

Online growth avoids a long outage where the filesystem supports it, but it still carries mapping, provider, and human-selection risk. Increasing size may change storage spend immediately while backup windows and restore time rise with data volume. Measure usable capacity at the mount, backup duration, and the service's write success after the operation. A screenshot of a larger provider disk is weak evidence if the mapper or filesystem stayed small. Keep a record of the exact stable identifier and layer sizes so the next operator does not infer the stack from a name such as /dev/sdb.

Common Mistakes

  • Do not treat a larger provider volume as proof the filesystem grew.
  • Do not select a block device from its transient kernel name alone.
  • Do not run a filesystem growth command before confirming its type and underlying capacity.

Connected lessons

Practice and check

devops
linux
storage-operations
Storage details