A disk running out of space, with no appetite for downtime — that’s exactly where cloud disk hot resizing earns its keep: enlarge the disk from the console, then stretch the partition and filesystem to match inside the system, with service uninterrupted throughout. This post walks the complete flow using a 50GB-to-100GB example. The operation splits into two halves: the platform side is only responsible for making the disk bigger; the three steps inside the system — confirm, stretch the partition, expand the filesystem — are what actually decide success or failure.

Test note: the flow in this post was fully reproduced on a Rocky Linux 9.3 container using a loop device (a 50M disk grown to 100M; the growpart and resize2fs outputs are all real measurements), with commands identical to those for a real cloud disk. The loop experiment requires a --privileged container: both losetup and mount need the privilege flags.

What Hot Resizing Is, and Where It Applies

Hot resizing means dynamically increasing storage capacity without shutting down the system or terminating services. It’s especially common in cloud environments — services must stay highly available, and you don’t stop a machine just to add disk space. Typical scenarios: business platforms with fast-growing data, databases that may not go down, big-data analysis that needs dynamic expansion, and container hosts. The common thread: “storage grows with the business, and the service cannot stop.”

Prerequisites: root or sudo privileges; a filesystem that supports online expansion (both ext4 and xfs do); and growpart present on the system (from the cloud-utils-growpart package — if missing, yum install cloud-utils-growpart first).

Step 1: Increase the Disk Capacity on the Cloud Platform

  1. Log into the cloud platform’s management console;
  2. Go to the “Storage” or “Disks” management page;
  3. Select the disk to enlarge and change its capacity, e.g. from 50GB to 100GB;
  4. Submit the operation and wait for the platform to finish expanding.

Step 2: Confirm the New Disk Space

Back in the Linux system, use lsblk to confirm:

1
lsblk

The expectation: sda now shows 100G — the disk is bigger while the partition is still 98G, meaning the platform-side expansion has landed; next, stretch the partition.

Step 3: Expand the Partition

Use growpart to stretch the partition across the disk’s available space:

1
sudo growpart /dev/sda 2

Output of CHANGED: partition=2 ... means success. Run lsblk once more and confirm sda2’s size has updated to around 98G.

Step 4: Expand the Filesystem

A bigger partition does not mean a bigger filesystem — the last step picks the command by filesystem type.

ext4:

1
sudo resize2fs /dev/sda2

xfs (note that xfs_growfs takes the mount point, not the device):

1
sudo xfs_growfs /

Confirm the result with df -h: when the Avail column climbs, the expansion is complete.

Tested: Simulating the Full Flow with a Loop Device

The four steps above were walked completely on a 50M loop device (a disk image file standing in for the cloud disk; all other commands unchanged):

1
2
3
4
truncate -s 50M /tmp/disk.img
losetup -f --show /tmp/disk.img          # yields /dev/loopN
echo "start=2048, type=83" | sfdisk /dev/loopN
mkfs.ext4 /dev/loopNp1 && mount /dev/loopNp1 /mnt/demo

Figure 1

Then the expansion followed the flow: truncate -s 100M to enlarge the image, losetup -c to sync the loop device, growpart to stretch the partition — in lsblk, the disk and then the partition went from 50M to 100M/99M in sequence:

Figure 2

Finally, resize2fs expanded the filesystem, with the before/after df comparison as acceptance:

Figure 3

The before/after df -h contrast is the most direct acceptance evidence: Avail rose from 38M to 83M — the filesystem genuinely got bigger. On a real 50GB→100GB cloud disk expansion, the numbers scale up proportionally.

Wrong-Way Comparison: Stopping at growpart

The most common half-finished job is calling it a day after growpart — the partition really did get bigger (lsblk shows it), but the filesystem didn’t follow: in df -h the Avail column doesn’t budge, and the alerts keep firing. Remember that the acceptance criterion is exactly one: the capacity in df -h goes up. Another easy mistake is using resize2fs on xfs — it only recognizes the ext family; on xfs it’s ineffective and throws an error. xfs’s entry point is xfs_growfs with the mount point.

Notes and Cautions

  • Back up important data before touching a disk — hot resizing generally doesn’t affect data, but better safe.
  • Confirm the filesystem (ext4, xfs) supports online expansion; a few older filesystems still require offline operations.
  • Each cloud platform has different limits and entry points for disk expansion, and some require unmounting the disk first — check your own platform’s documentation first.
  • Mind the per-expansion minimum and maximum limits; some platforms also constrain how often you can expand.
  • Tool versions for growpart, resize2fs, and the rest must support your OS and filesystem.

Summary

Back to the opening scenario: a full disk with no downtime comes down to the combination punch of “the platform grows the disk, the system follows.” lsblk confirms the disk landed, growpart stretches the partition, resize2fs or xfs_growfs expands the filesystem, and df -h signs off at the end — four steps, and the capacity is in the bag.

This article was rebuilt from the author’s CSDN blog posts published between 2020 and 2024, originally published on CSDN.