TL;DR: Three layers must agree: the kernel's view of the device, the partition entry, and filesystem metadata. Tell the kernel, grow the partition with growpart, then grow the filesystem: resize2fs for ext4, xfs_growfs against the mount point for xfs. Online growth is supported for common ext4/XFS layouts, but verify filesystem/kernel support, device identity and a recoverable backup first.
How to approach it
Find which layer lags before typing anything: device size as the kernel sees it, partition table entry, then filesystem. Supported growth runs bottom-up and can avoid downtime; say that early, because half your interviewers have watched someone schedule a reboot for this.
A strong answer
Confirm what the kernel sees first: lsblk shows the device's new capacity next to the stale partition size, and dmesg will carry a line like nvme0n1: detected capacity change from X to Y after a cloud-side resize. If lsblk already shows full size on an unpartitioned volume, skip straight to the filesystem step.
With a partition table in the way, growpart /dev/nvme0n1 1 extends into contiguous free space after that partition; it cannot grow through a later partition. It works on mounted root volumes because it uses the BLKPG interface to update the kernel's view live; done manually you would run partx -u /dev/nvme0n1 or partprobe to reread the table. On GPT disks grown from a smaller snapshot, the backup header sits at the old end of disk until moved, and growpart handles the common cases; if it complains, sgdisk -e relocates the header first.
Then the filesystem, and this is where candidates mix tools:
| Situation | Command | Notes |
|---|---|---|
| ext4, mounted | resize2fs /dev/nvme0n1p1 | online growth supported |
| xfs, mounted | xfs_growfs /data | takes the mount point, never the device |
| LVM logical volume | lvextend -r -l +100%FREE /dev/vg/data | -r chains the fs growth |
| Shrink ext4 | unmount, e2fsck, resize2fs | offline only, maintenance window |
Two details trip people constantly. XFS shrink support is version- and layout-dependent, so do not assume your installed kernel and tools support it; and xfs_growfs wants the mount point because it talks to the mounted filesystem, not the block device. With LVM under the cloud volume, order matters more, because there are four stacked layers and each only learns about the one below it when told. The chain is device, then partition, then physical volume, then logical volume, then filesystem: the cloud resize changes the device, growpart or partx -u updates the partition, pvresize teaches the physical volume about the new extents, lvextend hands them to the logical volume, and only then does the filesystem grow. Skipping a step does not error; it produces a no-op at the layer above, which is why a resize that appears to succeed can leave df unchanged and send people looking at the filesystem when the physical volume never learned anything.
Finish with verification rather than hope: df -h matches lsblk, and dmesg | tail is quiet. The whole sequence is minutes per host and fully scriptable; automation must handle a growpart no-change result separately from a real failure and verify every layer before continuing. A successful previous run does not replace precondition checks.
My position: automate this instead of ever running it by hand twice. Growth can be blocked by partition layout or unsupported storage layers. Shrinking is more restrictive: ext4 requires an offline workflow, and a verified backup/recreate/restore remains the general XFS fallback, so capacity planning should always leave headroom rather than plan shrink paths.
What interviewers probe next
"Can xfs be reduced?" Do not assume support. Check the deployed kernel/xfsprogs release and filesystem layout; experimental or limited shrink features are not a universal production procedure. Backup, recreate and restore is the general fallback.
"partprobe says the partition is busy." Use partx -u, which updates in place via BLKPG instead of rereading the whole table; growpart already does this internally.
"How do we stop getting these tickets?" Alert on trending free-percent weeks ahead of trouble, and pair auto-growing volumes with the grow-in-user-data pattern so humans stay out of the loop.
Common mistakes
Running resize2fs against an xfs volume, or xfs_growfs against a device name. Wrong-tool and wrong-argument are equally common here.
Stopping at the console resize and declaring victory while the partition still ends where it did before.
Rebooting "to make sure". It works by accident, wastes the window, and tells the interviewer you do not know which layer was stale.
References