Expanding Cloud Server Disks: Partition and Filesystem Steps

You increased the disk size in your cloud panel, but df -h still reports the old capacity. This usually means that only the virtual disk grew while the Linux partition, LVM structure, or filesystem still has its previous size.

A typical virtual disk has several layers: the virtual disk supplied by the cloud provider, a partition inside the operating system, an optional LVM physical volume (PV) and logical volume (LV), and a filesystem such as ext4 or XFS. The panel changes the first layer. You may need to expand the remaining layers from inside the server.

This guide covers common Linux layouts with LVM and direct ext4 or XFS partitions. Device names in the commands are examples. Do not copy a device name until your own output confirms that it is the correct disk or partition.

Why does the disk grow but free space not increase?

The visible symptom is a larger disk size in the panel while the root filesystem remains unchanged in df -hT. The kernel may still report the old disk size, the partition table may not include the newly available space, or the filesystem may still occupy its previous size.

A filesystem does not automatically use every block on the device beneath it. For example, the virtual disk /dev/sda may grow from 100 GB to 150 GB while /dev/sda3 remains 100 GB. The filesystem then cannot use the additional 50 GB.

The chain is longer with LVM. New space must move from the disk to the partition, then to the PV, volume group (VG), and LV. The filesystem is expanded last. If you skip a layer, capacity remains unavailable at the next layer.

Check the layout and prerequisites first

These procedures assume a Linux server with root or sudo access. The command names and package availability vary by distribution. The examples use standard tools commonly found on current Debian, Ubuntu, and RHEL-compatible systems; check your distribution documentation before installing a missing tool. Online filesystem growth also depends on the filesystem, kernel, distribution, and storage infrastructure.

Keep your SSH session open and, if possible, prepare a separate management session. Low space on the root filesystem can affect package installation and log writing. Reduce critical write activity and schedule data-changing steps within an appropriate maintenance window.

The following commands only read information. They show whether the operating system sees the new capacity, which partition is mounted, and which filesystem is in use. The LVM commands require the relevant LVM tools, usually provided by an lvm2 package.

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
findmnt -no SOURCE,FSTYPE,TARGET /
df -hT
sudo pvs
sudo vgs
sudo lvs

When LVM is not installed or not in use, pvs, vgs, and lvs may return an error or no output. That is not automatically a problem. If findmnt shows a source such as /dev/sda3, you likely have a direct-partition layout. A source in the form /dev/mapper/... usually indicates LVM.

If lsblk still shows the old size for the main disk after the panel operation, do not run partition or filesystem commands yet. Check that the provider operation has completed, whether the virtual disk supports online expansion, and whether a reboot or provider-specific rescan is required. If a reboot is necessary, assess its effect on the application first.

If the disk has the new size but the last partition is still smaller, and unallocated space follows it immediately, you may only need to expand that partition. Save the lsblk and findmnt output before changing the partition table. If the target is not the last partition, or another partition lies after it, growpart may not produce the expected result.

Expand a cloud server disk with LVM

LVM makes it easier to allocate disk capacity between logical volumes, but it adds storage layers. Assume, for illustration, that the root filesystem is on /dev/mapper/ubuntu--vg-ubuntu--lv and the LVM partition is /dev/sda3. Your names may be different.

Expand the physical partition

If lsblk shows that the main disk grew while the LVM partition did not, expand the partition. Debian- and Ubuntu-based systems can use growpart. Check whether it is available:

command -v growpart

If the command is missing, install cloud-guest-utils or the equivalent package through your distribution’s package manager. Package names vary by distribution. Installing a package may require repository access and free space, so confirm that your backup and rollback plan is ready first.

After verifying the disk and partition number against your own lsblk output, run:

sudo growpart /dev/sda 3
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

Here, /dev/sda is the disk and 3 is the partition number. Do not continue if the partition did not reach the expected size. GPT layouts or custom partition arrangements may require a different tool or sequence; when the layout is unclear, follow the documentation for your distribution and provider.

Expand the PV and LV

After the partition grows, the LVM physical volume may still have its old size. Check whether LVM can see the additional space with pvs and pvdisplay. If the PV is /dev/sda3, for example:

sudo pvresize /dev/sda3
sudo pvs
sudo vgs

Free space in the vgs output means that the volume group has capacity available. Decide which logical volume should receive it before running lvextend. If several LVs exist, assigning all free space to the wrong one can affect the application’s storage arrangement.

To add a specific amount, such as 40 GB:

sudo lvextend -L +40G /dev/mapper/ubuntu--vg-ubuntu--lv

To assign all free space in the volume group to this LV:

sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv

These commands enlarge the logical volume. The filesystem may not grow automatically in every configuration. Some systems allow lvextend -r to call the filesystem resize operation as well, but handling the layers separately makes each result easier to verify and gives you more control during a production change.

After either command, check lvs before resizing the filesystem. If the LV did not reach the intended size, stop and investigate rather than proceeding with an incorrect device.

Grow and verify the filesystem

For ext4, use resize2fs after the logical volume has grown. A mounted root filesystem can usually be expanded online, subject to the kernel and storage environment:

sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv
df -hT
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS

For XFS, specify the mounted path rather than the source device. For the root filesystem:

sudo xfs_growfs /
df -hT
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS

The xfs_growfs command is supplied by the xfsprogs package on many distributions. XFS growth is performed on the mounted filesystem. XFS cannot be reduced, so define your capacity plan before allocating more space than the application needs. Reducing ext4 is also a different and generally riskier operation that often requires the filesystem to be unmounted. The steps here are for expansion only.

Review three outputs together: pvs for the PV, lvs for the LV, and df -hT for the mounted filesystem. If the first two layers grew but df did not, the filesystem step is the missing layer. If df changed but the application still cannot use the space, investigate inode usage, quotas, or application-specific storage limits.

Expand a direct ext4 partition without LVM

If ext4 is installed directly on a partition, you do not need LVM commands. Confirm that the main disk grew and that the filesystem partition is adjacent to unallocated space at the end of the disk. In this example, the root filesystem is /dev/sda3 on /dev/sda.

Expand the partition with growpart:

sudo growpart /dev/sda 3
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

After confirming the partition size, expand the ext4 filesystem:

sudo resize2fs /dev/sda3
df -hT

The direct device is used here because the filesystem is not on LVM. Your findmnt output may show /dev/vda1, /dev/nvme0n1p1, or another device. NVMe partition names use a different format, so do not treat /dev/sda3 as a default.

Growing a mounted filesystem is possible in most ext4 installations, but behavior can vary with the kernel, distribution, and storage infrastructure. If resize2fs fails, record the error instead of repeatedly running the command. Confirm that the device is ext4 and that the partition is larger than the filesystem. If offline maintenance is required, stop the application and use a recovery environment or planned maintenance procedure.

Use the correct growth command for XFS

A common mistake on XFS systems is running resize2fs. That tool is for ext filesystems. Use xfs_growfs after confirming the type:

findmnt -no SOURCE,FSTYPE,TARGET /
df -hT /

For XFS directly on a partition, expand the partition first, verify it, and then grow the mounted filesystem:

sudo growpart /dev/sda 3
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sudo xfs_growfs /
df -hT /

This example applies only when the root filesystem is on /dev/sda3 and mounted at /. If XFS is mounted at a data path such as /var/lib, use /var/lib in the final command. With LVM, expand the relevant partition, PV, and LV first; run xfs_growfs only after the LV has its new size.

Make sure the target mount point is mounted before growing XFS. Afterward, use df -hT to check the filesystem size. You can also perform a small, controlled write test in the directory used by the application, then remove the test data and avoid changing application permissions.

Verify the result and plan rollback

Do not rely only on the size shown in the cloud panel. These checks show whether each layer sees the new capacity and whether the mounted filesystem gained usable space:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
df -hT
findmnt -no SOURCE,FSTYPE,TARGET /
sudo pvs 2>/dev/null
sudo vgs 2>/dev/null
sudo lvs 2>/dev/null

If the new capacity is visible but free space is lower than expected, check whether deleted files are still held open by running processes. That issue is separate from disk expansion. Also check inode usage with df -ih, and inspect vgs for unallocated space in the volume group. Application quotas or internal storage settings may prevent the application from using operating-system space.

Changes to partition or LVM sizes generally do not shrink existing capacity. If you expanded the wrong LV, reversing the change depends on the filesystem type and how much space is in use. XFS cannot be reduced. For that reason, rollback often means reverting to a pre-change snapshot or restoring the backup to another disk. Do not attempt a reduction as an improvised rollback.

If SSH disconnects during the procedure, do not blindly rerun every command. Reconnect and collect lsblk, pvs, lvs, and df -hT first. If one step completed, perform only the missing layer. A command having run previously does not make a wrong device selection safe.

Frequently Asked Questions

Can I expand the disk without rebooting?

Many virtual disk platforms support online disk and filesystem expansion. Whether the new size is detected without a reboot depends on the provider, operating system, and disk type. If lsblk still reports the old size, a planned reboot or the provider’s rescan procedure may be required.

Why did du not change after the disk expansion?

du totals space used by existing files in directories; it does not report unused capacity. Use df -hT for available filesystem space and lsblk for disk and partition sizes.

Should I assign all free space to the root LV?

No. If separate LVs hold databases, logs, or user files, consider their future needs before using +100%FREE. Use that option only when you deliberately want all VG free space assigned to the selected LV.

Does the application need to restart after the filesystem grows?

A capacity increase alone usually does not require an application restart. An application that caches quota or storage information may need its own refresh procedure, but that is separate from filesystem expansion. CLI queue workers also do not occupy PHP-FPM workers unless they make HTTP requests; do not treat a queue process as part of this disk-resize procedure.

Actionable checklist

• Confirm that the panel operation completed and check whether a reboot or provider rescan is required.
• Verify that the backup or snapshot can actually be restored.
• Map the layout with lsblk, findmnt, and df -hT.
• Do not run partition or filesystem commands while the disk still shows its old size.
• Confirm that unallocated space directly follows the target partition.
• With LVM, preserve the order: partition, PV, LV, then filesystem.
• Use resize2fs for ext4 and xfs_growfs for XFS.
• Measure capacity after every layer and recheck the device name.
• Perform a safe verification at the mount point used by the application.
• Keep the pre-change snapshot or backup until the application has been checked.

Your next step is to collect the read-only command output from the server and identify the correct layout. Do not run a partition or LVM command until that output confirms the target device. If you are also planning capacity for IOPS and inode usage, review What is a Cloud Server? and the related disk, IOPS and inode planning guidance before choosing the next disk size.