How to Increase a VPS Disk and Expand ext4, XFS, or LVM on Linux

After expanding the disk in the provider’s control panel, the additional space may not be immediately available within Linux. First, you need to determine which layer still reports the old size: the disk, partition, LVM, or file system.

Basic checks:

   lsblk
lsblk -f
df -hT

If the disk has grown but the partition has not, the following command usually helps: sudo growpart /dev/sda 1

For ext4, expand the file system afterward: sudo resize2fs /dev/sda1

For XFS, specify the mount point: sudo xfs_growfs /

If LVM is in use, the process involves additional steps:

   sudo growpart /dev/sda 3
sudo pvresize /dev/sda3
sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

Then expand the filesystem within the logical volume using resize2fs or xfs_growfs.

Before modifying partitions and LVM, create an up-to-date backup and record the original layout using lsblk, fdisk -l, pvs, vgs, and lvs.

Final checks:

   lsblk
df -hT

For LVM, also run:

   sudo pvs
sudo vgs
sudo lvs

If lsblk shows the new capacity but df -hT still shows the old capacity, the block storage has already been expanded, but the filesystem has not. This is the simplest way to troubleshoot problems after resizing.

What Happens After You Expand a Disk through Your Provider

Welcome!

Today, we will examine a situation that seems deceptively simple: you open your cloud provider’s control panel, expand a VPS disk, see the new capacity in the interface, and expect Linux to immediately report the corresponding increase in free space.

In practice, however, things often work differently.

Suppose the disk size was: 40 GB

You increased it to: 80 GB

Everything looks correct in the provider’s control panel, and only one command is needed within the system: df -h

still shows the old file system size.

This is where the confusion begins.

The user thinks, “I’ve already expanded the disk. Why can’t Linux see the additional space?”

Because expanding the virtual disk with the provider is only the first layer.

Linux must then:

• Detect the disk’s new size;
• Extend the partition if necessary;
• If LVM is used, extend the Physical Volume and Logical Volume;
• Then expand the file system itself;
• Only then will the additional space actually become available to applications.

In other words, clicking “Resize disk” in the cloud control panel does not always mean, “Done—you now have more free space in /.”

More often, it means, “The physical or virtual block device is now larger. You must now properly extend everything layered on top of it.”

Providers generally handle all of this automatically using cloud-init scripts. However, if the provider did not configure this in the image, or if the system was installed from a custom image, you will need to extend the partition manually.

We will cover this entire process.

We will cover three common scenarios separately:

• A standard partition with ext4;
• A standard partition with XFS;
• A disk that uses LVM.

Let’s move on

Why Linux Does Not Always Use the New Capacity Immediately

Let’s start with the most important distinction.

The command lsblk and the command df -h show different information.

The first shows block devices and partitions.

The second one, namely df, shows the size of the mounted file systems.

For example, after expanding a disk, you may encounter the following situation:

The disk itself has already grown to 80 GB.

However, the sda1 partition remains at 40 GB.

This means that the file system within it cannot use the remaining 40 GB.

Even after expanding the partition, the process may not be complete.

For example:

but: df -h still shows 40 GB.

This means that the partition has already been expanded, but the file system within it has not.

In other words, there are several independent layers, each of which can have its own size.

This is why resizing is best performed in stages.

The Difference Between Disks, Partitions, LVM, and File Systems

To avoid confusion with the commands later, let’s review the main storage layers.

Disk

This is the block device itself.

For example: /dev/sda or /dev/vda

After you expand the disk in the provider’s control panel, this is usually the first layer to increase in size.

For example: /dev/sda → 80 GB

Partition

A disk can contain partitions.

For example:

/dev/sda1

/dev/sda2

/dev/sda3

A partition is an allocated portion of a disk.

Even if the entire /dev/sda disk has been expanded, a specific partition such as /dev/sda1 will not necessarily expand automatically to use the newly available space.

This is why growpart or another partition table modification tool will be needed later.

LVM

LVM adds another layer of abstraction between the partition and the filesystem.

Instead of the direct layout: partition → filesystem

The layout becomes: partition → Physical Volume → Volume Group → Logical Volume → filesystem

LVM enables flexible logical volume management, but resizing involves a few more steps.

After expanding the disk, you need to check several layers:

• partition;
• PV;
• VG;
• LV;
• filesystem.

Next, we move on to the final—but no less important—case.

File System

Finally, the file system resides on a partition or logical volume.

The most common file systems are ext4 and XFS.

It is the file system that determines how much space regular applications and the following command can see: df -h

For users, the most important distinction is therefore as follows:

Even if one layer has been expanded, this does not guarantee that the next layer has expanded automatically as well.

How to determine which storage configuration your VPS uses

Before running any resize commands, you need to understand the current storage layout.

Let’s start with: lsblk

For example, a standard partition might look like this:

NAME   MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS

This configuration is fairly straightforward:

• The /dev/sda disk is 80 GB;
• The /dev/sda1 partition is 40 GB;
• The root filesystem, /, resides directly on this partition.

This is a standard configuration without LVM.

Now let’s check the file system type: lsblk -f

For example:

This means we have a standard partition with ext4.

If we see: xfs, the procedure will differ only at the filesystem expansion stage.

An LVM configuration looks different.

For example:

Here you can already see: TYPE=lvm

This immediately indicates that there is an additional layer between the partition and the filesystem.

You can confirm this using the following commands:

   sudo pvs
sudo vgs
sudo lvs

If they show a Physical Volume, Volume Group, and Logical Volume, the system is using LVM.

Another useful command: df -hT

It shows the size and type of the mounted filesystem.

For example:

This immediately shows that:

• The root filesystem resides on an LVM Logical Volume;
• The filesystem is ext4.

This is precisely why we will not provide one long sequence of commands for every possible configuration.

Let’s move on.

Before expanding: create a backup and verify the current layout

Now that we understand the architecture, we are moving on to a stage where it is better to spend an extra five minutes checking everything than several hours recovering later.

Expanding a disk, partition, or file system is generally considered a routine operation. Modern ext4 and XFS file systems and LVM volumes can be expanded without reinstalling the operating system and, in many cases, without stopping services.

However, there is an important caveat: an error at the partition table or LVM level can affect the underlying data storage structure.

Therefore, before running growpart, pvresize, or resize2fs for the first time, you should record the initial state and have a way to roll back.

Why Resizing Is Usually Safe but a Backup Is Still Necessary

Increasing capacity is generally less risky than reducing it.

We are not trying to shrink the file system or move data to a smaller volume. Instead, we are adding free space to the existing structure.

However, some risk remains.

For example, you could:

• Select the wrong disk;
• Extend the wrong partition;
• Use the wrong partition number;
• Confuse one LVM Logical Volume with another;
• Modify the partition table incorrectly;
• Encounter an issue with the cloud disk;
• Run the command on a production server that already has hardware or file system errors.

Therefore, before resizing, it is best to have an up-to-date backup of the data.

If your cloud provider supports snapshots, it is a good idea to take a snapshot of the disk or the entire VM before making any changes.

However, a snapshot is not always a substitute for a proper backup.

If a database is actively writing to disk, a crash-consistent snapshot may capture data in an intermediate state. For critical databases, it is best to use the DBMS’s built-in backup mechanism beforehand.

For example, a possible preparation plan might look like this:

   Application files
→ backup
Database
→ separate dump / native backup
Cloud disk
→ snapshot

You do not always need to use all three methods. However, you should have at least one viable recovery option.

Checking Disks, Partitions, and Mount Points

Now, record the current state.

Let’s start with: lsblk

This command displays block devices, partitions, LVM, and mount points.

For example:

An important detail is immediately apparent:

• The /dev/sda disk is already 80 GB;
• The root partition, /dev/sda2, is only 39 GB.

This means that the system has detected the disk’s new capacity, but the partition has not yet been expanded.

Let’s add file system information: lsblk -f

And let’s check the mounted file systems separately: df -hT

For example:

This shows that / uses ext4.

It is also useful to check the partition table: sudo fdisk -l

The fdisk -l command displays disk and partition sizes, as well as partition boundaries.

Before making changes, it is advisable to save the output to a file: sudo fdisk -l > ~/disk-layout-before.txt

Also run:

   lsblk -f > ~/lsblk-before.txt
df -hT > ~/df-before.txt

This is not a data backup, but rather a convenient checkpoint.

If anything looks unusual after resizing, you can compare the original and updated layouts.

Determining the File System Type

Now we need to determine exactly which file system we will be extending.

The simplest option: df -hT or lsblk -f

For example: /dev/sda2  ext4 this means resize2fs will be needed next.

If: /dev/sda2  xfs, the file system will be expanded using xfs_growfs.

You can check a specific mount point: findmnt /

For example:

findmnt is particularly useful when a server has multiple disks and partitions.

It lets you quickly determine which device is actually used for /.

For a different directory: findmnt /var or findmnt /data

This is important because you must extend the device that contains the required mount point.

Check LVM if it is in use

If lsblk shows TYPE=lvm, checking the partitions alone is not enough.

Let’s examine the three LVM layers.

• Physical Volumes: sudo pvs
• Volume Groups: sudo vgs
• Logical Volumes: sudo lvs

Up to €20,000 in EU-Based IaaS Credits

Frankfurt infrastructure, predictable pricing, and expert migration support.

Get

For example:

Here, the Physical Volume /dev/sda3 is part of the Volume Group ubuntu-vg.

And:

shows the Logical Volume.

It is also useful to run lsblk and correlate all the layers.

For example:

If this is the root disk, findmnt / will show: /dev/mapper/ubuntu--vg-ubuntu--lv

In other words, you cannot extend /dev/sda3 directly as a regular file system here.

First, you will need to:

• Extend the partition;
• Then the Physical Volume;
• Then the Logical Volume;
• And only then the file system.

Before working with LVM, you can also save the initial state:

   sudo pvs > ~/pvs-before.txt
sudo vgs > ~/vgs-before.txt
sudo lvs > ~/lvs-before.txt

At this point, you should have a complete picture:

• Which disk was expanded;
• Which partition is in use;
• Which file system is on top of it;
• Whether LVM is in use;
• Which Logical Volume is mounted at the required mount point.

Only then does it make sense to proceed with resizing.

Checking Whether Linux Detects the New Disk Size

After expanding the disk in the provider’s control panel, the first thing to check is not the file system or the partition, but the block device itself.

This is an important step because the rest of the process depends on it.

If Linux still reports the disk at its previous size, there is no point in running growpart or extending LVM yet. The operating system must first detect the device’s new capacity.

Checking the disk size before and after expansion

Let’s start with the most illustrative command: lsblk

Suppose the output looked like this before the expansion:

NAME   SIZE TYPE MOUNTPOINTS

After increasing the disk size to 80 GB through the provider, we expect to see:

This exact output indicates that the disk itself has already been expanded, while the partition has remained unchanged.

This is normal.

You can also check the size using: sudo fdisk -l /dev/sda

At the beginning of the output, you will see something like: Disk /dev/sda: 80 GiB

Another convenient option: lsblk -b

It displays sizes in bytes when you need to compare values as precisely as possible.

At this stage, it is important not to confuse: /dev/sda and /dev/sda1

The first is the entire disk.

The second is a separate partition within it.

If /dev/sda already shows the new capacity, the next step is to work with the structure within the disk.

If /dev/sda itself still shows the old size, you must first make the system reread the device size.

If the new capacity does not appear immediately

In cloud environments, the system often detects changes to a virtual disk’s size automatically.

However, this does not always happen immediately.

For example, the provider already shows 80 GB, but inside the VPS, lsblk still reports sda 40G

First, simply check again after a few seconds or minutes.

If the size has not changed, you can instruct the kernel to rescan the device.

For SCSI disks, one common option is: echo 1 | sudo tee /sys/class/block/sda/device/rescan

After that, run again: lsblk

Be sure to replace sda with the name of your actual disk.

If the device is named vda or nvme0n1, the path and rescan method may differ.

Therefore, before using a sysfs command, be sure to first determine the device type using: lsblk

For NVMe disks, it is often easier to check the device again using system tools or reboot the system, unless the provider requires a different procedure.

You can also ask the kernel to reread the partition table: sudo partprobe

However, it is important to understand the distinction here.

The primary purpose of partprobe is to instruct the kernel to reread the partition table.

It does not cause the system to detect the new size of the virtual disk itself.

In other words, “the disk is still 40 GB” and “the disk is 80 GB, but the partition is still 40 GB” are two different situations.

In the first case, the issue is at the device level.

In the second case, the disk is already detected at the correct size, and you can proceed with expanding the partition.

When to Rescan and When a Reboot Is Sufficient

In most cloud environments, there are two common scenarios.

In the first scenario, the system detects the new size without a reboot.

Then simply run: lsblk to see the new volume and continue working.

In the second scenario, the size is not updated.

In this case, you can rescan the device if you know what type of disk is being used and the provider allows this operation.

For example: echo 1 | sudo tee /sys/class/block/sda/device/rescan

If the device is behaving unexpectedly, the provider’s documentation recommends rebooting, or you prefer not to work with sysfs manually, simply running sudo reboot is often the easiest option.

After reconnecting the device, check again:

   lsblk
sudo fdisk -l

Proceed only after the disk itself reports the new size.

It is useful to follow a simple verification sequence here:

1. Check the disk size with lsblk.
2. If it still shows the old size, rescan the device or reboot the system.
3. Check again.
4. Only after the new size appears should you proceed with the partition, LVM, and file system.

This prevents us from trying to expand the upper layers before the underlying layer has received the additional space.

In the next step, we will expand a regular partition with growpart and verify that it now occupies the free space on the disk.

Extending a Standard Partition

As noted at the end of the previous chapter, the disk itself already shows the new capacity. Now check whether the existing partition has expanded to occupy the newly available space.

If not, extend the partition first, and then proceed to ext4 or XFS.

When the Partition Must Be Extended First

A typical scenario looks like this:

Here, disk /dev/sda has already been expanded to 80 GB, but partition /dev/sda1 still occupies only 40 GB.

The remaining 40 GB is still unallocated disk space and is unavailable to the file system.

In this situation, you cannot simply run: sudo resize2fs /dev/sda1 and expect the file system to magically expand to fill the entire disk.

resize2fs expands the file system within an existing partition. If /dev/sda1 itself remains at its original size, the file system has no room to grow.

Therefore, the procedure is as follows:

1. The disk has already been expanded;
2. extend the partition;
3. then extend the file system.

However, if lsblk already shows:

there is no need to extend the partition again.

In that case, you can proceed directly to ext4, XFS, or the next LVM layer.

Extending a Partition with growpart

The growpart utility is commonly used to extend partitions in Ubuntu.

It is included in the package: cloud-guest-utils

Install it if the package is not already installed:

   sudo apt update
sudo apt install -y cloud-guest-utils

Now let’s take another look at the layout: lsblk

Suppose we have:

The command will then be: sudo growpart /dev/sda 1

Pay close attention to the syntax here.

We specify /dev/sda as the disk itself, and then separately 1 as the partition number.

So the correct command is: sudo growpart /dev/sda 1

not: sudo growpart /dev/sda1 1

This is because growpart must first be given the entire device and then locate the required partition within it.

If the root partition is, for example, /dev/sda3, the command will be: sudo growpart /dev/sda 3

For the /dev/vda disk: sudo growpart /dev/vda 1

Therefore, always check lsblk before running the command instead of copying a partition number from someone else’s example.

If the partition can be extended, growpart will adjust its boundary to occupy the available free space immediately following it.

The output typically shows the partition’s old and new sizes.

Checking the new partition size

Immediately after running growpart, check the result: lsblk

We should now see approximately the following:

You can also view the partition table: sudo fdisk -l /dev/sda

And verify that /dev/sda1 now spans the new range.

If the kernel did not immediately update the partition table information, run: sudo partprobe

and run again: lsblk

However, there is an important point to keep in mind.

Even if the partition already shows 80 GB, the command: df -hT may still show the old file system size.

For example:

This is not an error.

The partition has already been expanded, but the file system has not yet been resized.

This is where we clearly distinguish between the two layers:

• lsblk shows the partition size;
• df -hT shows the file system size.

The free space is now part of the partition.

The next step depends on the file system type: use resize2fs for ext4 and xfs_growfs for XFS.

Extending an ext4 File System

Verify That ext4 Is in Use

Before running resize2fs, do not rely on memory or someone else’s example.

Let’s check the file system type: lsblk -f Or df -hT

For example:

This output shows that the root file system uses ext4.

You can also check a specific mount point: findmnt /

If the FSTYPE field is set to ext4, you can proceed.

Expanding the File System with resize2fs

For ext4, use the following command: sudo resize2fs /dev/sda1

Here, we specify the device that contains the file system.

If the partition has a different name, for example: /dev/vda1, then the command will be: sudo resize2fs /dev/vda1

If ext4 is inside LVM, the path will be different, for example: /dev/mapper/ubuntu--vg-ubuntu--lv

We will cover LVM separately in the next major section.

For a standard partition, resize2fs detects the available space and expands the file system to the maximum size supported by the device.

In many cases, ext4 can be expanded while mounted.

This means that the root file system mounted at / does not necessarily need to be unmounted beforehand, nor does the server need to be shut down.

After running the command, you may see a message like this: The filesystem on /dev/sda1 is now … blocks long.

This means that the file system has taken up the additional space in the partition.

Verify the Result

Now run the following command again: df -hT

If it previously showed: /dev/sda1  ext4   39G, then after expansion, we expect a value close to the partition’s new size: /dev/sda1  ext4   78G

Why Isn’t It Exactly 80 GB?

Because some space is used for file system metadata, and units of measurement may also vary slightly between tools.

You can also compare:

   lsblk
df -hT

The partition and file system sizes should now be consistent.

Extending an XFS File System

The process is similar for XFS: first, extend the disk and partition, and then the file system.

However, the command and the way the file system is specified are different.

How extending XFS differs from extending ext4

For ext4, we used: resize2fs /dev/sda1

In other words, the command was given a block device.

For XFS, the following is typically used: xfs_growfs and you specify the mount point.

For example, if XFS is mounted as the root filesystem: /, the command will be: sudo xfs_growfs /

If the file system is mounted at: /data, then: sudo xfs_growfs /data

This is an important distinction.

Do not automatically substitute /dev/sda1 just because it was used in the ext4 example.

Expanding XFS with xfs_growfs

First, verify that XFS is actually being used: df -hT

For example:

Full Control Over Your Kubernetes Infrastructure

Deploy production-ready Kubernetes with full control over nodes, storage, and networking on predictable-cost EU infrastructure with direct access to your resources.

Get

Or: findmnt /

If we see: FSTYPE xfs — it can be expanded.

For the root file system: sudo xfs_growfs /

The command determines the size of the underlying device and expands the XFS file system to the maximum available size.

XFS can also be expanded while mounted.

Therefore, the server does not need to be stopped for a standard online expansion of the root file system.

After the command completes, you can view information about the old and new block counts.

Verify the Result

Check again: df -hT

For example:

You can also check: xfs_info /

The command displays the XFS parameters, including the file system size.

For a different mount point, for example, /data: xfs_info /data

For standard partitions, the key difference is the tool used:

On a standard VPS, this is often sufficient.

Expanding a Disk with LVM

With standard partitions, the process is relatively straightforward: expand the disk itself, then the partition, and finally the file system.

LVM adds an extra layer.

That is why it is particularly important not to jump straight to resize2fs or xfs_growfs, but to work through each layer in the correct order.

How the LVM Stack Works

LVM stands for Logical Volume Manager, a layer for managing logical volumes on top of standard block devices.

For beginners, it is easiest to think of it as a stack of several layers:

Partition

• → Physical Volume
• → Volume Group
• → Logical Volume
• → file system

For example:

• /dev/sda3
• → PV
• → ubuntu-vg
• → ubuntu-lv
• → ext4

or XFS at the final layer.

Each layer has its own size.

Therefore, after expanding the disk through your provider, you may encounter the following situation:

• The disk has already grown to 100 GB;
• The LVM partition is still 50 GB;
• The Physical Volume is still 50 GB;
• The Logical Volume is still 50 GB;
• The file system is also still 50 GB.

In other words, the additional space currently exists only at the underlying disk level.

You can check the current layout as follows: lsblk

Check LVM separately:

   sudo pvs
sudo vgs
sudo lvs

For example:

If the disk has already grown but PSize remains unchanged, the free space has not yet reached LVM.

Extending a Partition Containing an LVM Physical Volume

First, extend the partition that contains the Physical Volume.

Suppose lsblk shows the following:

Then extend the third partition: sudo growpart /dev/sda 3

A reminder of the syntax: /dev/sda 3, where /dev/sda is the entire disk and 3 is the partition number.

After that, verify: lsblk

Now we expect something like this:

Important: The Logical Volume may still be its original size.

So far, we have only expanded the container that holds the LVM Physical Volume.

Extending the Physical Volume with pvresize

Now you need to tell LVM that the Physical Volume has increased in size.

To do this, run: sudo pvresize /dev/sda3

The command will reread the device size and extend the PV to use all available capacity.

Verify: sudo pvs

Free space may now appear:

This is an important step.

PFree shows how much space is now available within the Volume Group for logical volumes.

You can also check: sudo vgs

For example:

In other words, the Physical Volume and Volume Group now recognize the additional capacity, but the Logical Volume is not using it yet.

Extending the Logical Volume

Now, extend the required logical volume.

First, let’s check its name again: sudo lvs

For example:

Alternatively: lsblk, where the path may look like this: /dev/mapper/ubuntu--vg-ubuntu--lv

To allocate all free space in the Volume Group to the logical volume: sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

You can also use the path under /dev/mapper if it is identified correctly.

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

After that, verify: sudo lvs

The LV should now be larger.

It is important to understand that +100%FREE means using all free space in the Volume Group.

If the VG contains multiple logical volumes and some free space must be left for other purposes, this option may be too aggressive.

The size can then be increased, for example, by 20 GB: sudo lvextend -L +20G /dev/ubuntu-vg/ubuntu-lv

In other words:

• -L +20G — add a specific amount of space;
• -l +100%FREE — use all free space.

Let’s continue.

Extending the File System Inside LVM

At this point, the logical volume has already been extended.

However, the file system inside it may still be its original size.

If using ext4: sudo resize2fs /dev/ubuntu-vg/ubuntu-lv or sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

After that: df -hT should show the new size.

If the file system on the LVM logical volume is XFS, a different command is required.

First, determine the mount point: findmnt /

For example, if the required Logical Volume is mounted at /, extend it: sudo xfs_growfs /

For /data: sudo xfs_growfs /data

In other words, LVM modifies the block layer, while the final command depends on the file system type.

There is also a shorter version: sudo lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

The option -r instructs LVM to automatically extend the file system along with the Logical Volume.

This is convenient, but for learning purposes, it is better to first understand what actually happens at each layer.

Otherwise, it is easy to memorize a single “magic” command without understanding where to look for the problem if automatic expansion fails.

For LVM, the key sequence is:

• partition
• → pvresize
• → lvextend
• → extend the file system

If you skip one of these layers, the next layer will not see the newly available space.

Verifying the Result After Resizing

The main work is complete: the disk has been enlarged, the partition extended if necessary, LVM updated, and the file system expanded to use the new space.

However, it is too early to consider the task complete simply because the commands ran without errors.

After resizing, make sure the new capacity is visible at all required layers and is actually available to applications.

It is useful to compare several commands here, as each one shows a different part of the overall picture.

Comparing lsblk and df -hT

Let’s start with the two most useful tools: lsblk and df -hT

They answer different questions.

lsblk shows how the system sees disks, partitions, and logical volumes.

For example:

NAME   SIZE TYPE MOUNTPOINTS

This output shows that:

• The disk itself is 80 GB;
• The partition is also 80 GB;
• The partition is mounted at /.

However, this alone is not enough.

Now df -hT may show:

This confirms that the file system has actually been expanded and the additional space is now available to users and applications.

This is why lsblk and df should be checked together.

If:

• lsblk → 80G
• df    → 40G

This means that the block layer has already been expanded, but the file system has not.

If both tools show the new size, the expansion process has completed successfully.

Checking LVM, if used

On a server using LVM, checking df alone is not enough.

Make sure the new capacity has propagated through all LVM layers.

First, let’s look at the Physical Volume: sudo pvs

For example:

If PSize reflects the new size, pvresize was successful.

Now the Volume Group: sudo vgs

If all free space was allocated to the logical volume after running lvextend -l +100%FREE, VFree will be close to zero.

For example:

Next, check the Logical Volume: sudo lvs

For example:

This means that all layers are consistent.

However, if you intentionally left some free space in the volume group, a nonzero VFree value is normal.

For example: VFree = 20G, could mean that you intentionally extended the LV by only 30 GB, leaving the remaining space for another logical volume.

The key is not to look for a single “correct” value, but to verify that the result matches your plan.

Verify That the New Space Is Actually Available

The final check is the most practical one.

We need to verify not only that Linux detects the new size, but also that the additional free space is actually available at the intended mount point.

For the root filesystem: df -h /

For /data: df -h /data

For example, before the expansion:

and after:

This is the intended outcome of the entire process.

The existing data remains in place, while the Avail value has increased noticeably.

You can also verify that the file system remains writable.

For example:

touch /tmp/resize-test

ls -l /tmp/resize-test

rm /tmp/resize-test

This does not test the entire newly added capacity, but it confirms that the file system remains available for normal operations after resizing.

For a separate disk mounted at /data, you can perform a similar check:

   touch /data/resize-test
rm /data/resize-test

For a production server, you should also verify after the expansion that the main services continue to operate.

For example: sudo systemctl --failed

The command displays services that are in a failed state.

For a specific service: sudo systemctl status nginx --no-pager or sudo systemctl status postgresql --no-pager

The final diagnostic checks can be summarized in a short table:

At this point, the expansion can be considered successfully completed.

The disk, partition, LVM, and file system are consistent with one another, and the additional space is now available to the system.

If any layer still shows the old size, the next section will help you quickly identify exactly where the process broke down.

If the Size Has Not Increased: Troubleshooting Common Issues

High-Performance Virtual Machines

Deploy in seconds with full root access, reserved resources, built-in high availability, and predictable monthly pricing.

Get

The disk has been expanded, but the partition remains unchanged

This is one of the most common scenarios.

For example: lsblk shows:

NAME   SIZE TYPE MOUNTPOINTS

The disk is now 80 GB, but the partition is still 40 GB.

This means that free space is already available, but it is not yet part of /dev/sda1.

In this case, you first need to expand the partition: sudo growpart /dev/sda 1

After that: lsblk should show the new size.

If the partition still has not changed, check the partition table: sudo fdisk -l /dev/sda

At this point, you can determine whether there is any free space immediately after the target partition.

This is important because growpart cannot magically skip over other partitions.

For example, if the layout looks like this:

you cannot simply extend sda1 to the end of the disk because sda2 lies between it and the free space.

In this case, the disk must be repartitioned more carefully, and this should not be attempted with a single growpart command.

The partition has grown, but df still shows the old size

Consider the following situation: lsblk shows:

but: df -hT still shows: /dev/sda1  ext4  40G

At this point, the partition is no longer the issue.

The partition has grown, but the file system within it remains at its previous size.

If it is ext4: sudo resize2fs /dev/sda1

If it is XFS, first check the mount point: findmnt /

And then, for example: sudo xfs_growfs /

After that, run again: df -hT

df—not just lsblk—must show the newly available capacity.

This is a good example of why a resize cannot be assessed using a single command.

lsblk may already look exactly as expected, even though applications still see the file system at its old size.

LVM Does Not Detect Free Space

With LVM, the issue can occur at several layers.

Suppose the LVM partition has already been expanded: sda3  100G, but sudo pvs still shows a Physical Volume size of 50 GB.

Therefore, run: sudo pvresize /dev/sda3

Then check:

   sudo pvs
sudo vgs

The new capacity should now appear as free space within the Volume Group.

For example: PFree  50G or VFree  50G

If the VG already has free space but df still shows the old size, the next layer—the Logical Volume—has not yet been extended.

Verify: sudo lvs

Then extend the required LV: sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

After that, do not forget to resize the file system.

For ext4: sudo resize2fs /dev/ubuntu-vg/ubuntu-lv

For XFS: sudo xfs_growfs /

In other words, if LVM does not “see” the new space, check each layer in turn:

• Has the partition been expanded?
• Has the PV been expanded?
• Is there now free space in the VG?
• Has the LV been expanded?
• Has the file system been expanded?

Let’s move on.

growpart reports that there is nothing to expand

Sometimes, after running the command sudo growpart /dev/sda 1, you may receive a message indicating that the partition cannot be expanded any further.

This is not always an error.

There are several possible reasons.

First, the partition may already occupy all the available space.

Check: lsblk and sudo fdisk -l /dev/sda

If the disk and the partition are already approximately the same size, growpart simply has nothing left to do.

Second, Linux may not yet have detected the disk’s new size.

For example: sda  40G

Even though the provider’s control panel already shows 80 GB.

In that case, rescan the device or reboot the system before attempting to modify the partition.

Third, the free space may not be located immediately after the target partition.

As noted above, having 40 GB of free space somewhere on the disk does not necessarily mean that a specific partition can simply be extended into that space.

Another possibility is that the partition has already been expanded and the user is simply running growpart again, even though the issue is now at the filesystem level.

ext4 or XFS will not expand

If the partition has already been expanded but the file system itself has not grown, first check its type again: lsblk -f or df -hT

This may seem obvious, but it is quite easy to accidentally run: resize2fs on XFS or try to use xfs_growfs on an ext4 filesystem.

For ext4, you should also ensure that the correct device is specified: findmnt /

For example:

   SOURCE=/dev/sda1
FSTYPE=ext4

Then: sudo resize2fs /dev/sda1

If LVM is used, the device may instead be: /dev/mapper/ubuntu--vg-ubuntu--lv, rather than /dev/sda3.

For XFS, you need to check the mount point specifically.

For example: findmnt / and then sudo xfs_growfs /

If the command reports that the file system is already at its maximum size, the issue is most likely at a lower layer: the partition or Logical Volume has not yet been expanded.

Another useful step is to check the system messages: sudo dmesg | tail -n 50 or sudo journalctl -k -n 50 --no-pager

If the device has errors, the file system is corrupted, or the kernel cannot correctly reread the disk geometry, this information will often appear there.

Ultimately, diagnostics usually come down to one principle: “First, identify the first layer that still shows the old size.”

In summary:

• If the disk itself still shows the old size, the issue is below the partition layer.
• If the partition still shows the old size, use growpart.
• If the PV or LV still shows the old size, move on to LVM.
• If all block-device layers have expanded but df still shows the old size, the issue is at the file system layer.

This serves as a step-by-step checklist.

There is one more point to clarify in today’s discussion.

How to Resize Safely in Production

Expanding a disk typically does not require stopping the server and, in many cases, proceeds without issues. However, the cost of an error is much higher in a production environment than on a test VPS.

If the server runs a database, API, website, or other critical services, changing the disk layout should be treated as a full-scale infrastructure operation rather than a series of harmless commands.

The main risk lies not in resize2fs or xfs_growfs themselves, but in changing the storage layout. Selecting the wrong device, partition, or logical volume can have far more serious consequences than a typical Nginx configuration error.

In production, predictability matters more than speed: know the existing storage layout in advance, have a backup, and understand how to restore the service to an operational state if something does not go according to plan.

Why shrinking a disk is a separate, riskier task

In this article, we focused specifically on expanding the disk and file system.

This is critically important.

When extending a volume, the process is relatively safe: new free space is added “to the right” of the existing data, and the file system is then allowed to use it.

With shrinking, the process is reversed.

First, you must ensure that the data physically fits within the new, smaller capacity. You must then shrink the file system, followed by the partition or logical volume, and only then the disk itself—if the provider supports shrinking it at all.

Performing these steps in the wrong order may leave some data beyond the new partition boundary.

It is especially important to remember this about XFS: XFS does not natively support shrinking the file system.

In other words, the following scenario:

   100 GB XFS
→ shrink to 50 GB

cannot be handled with a simple reverse equivalent of xfs_growfs.

Typically, this type of shrinking involves creating a new file system of the required size, migrating the data, and then switching the mount point.

Shrinking ext4 is possible, but it is more complex than extending it and usually requires unmounting the file system.

When to Schedule a Maintenance Window

Many expansion operations can be performed online.

For example:

• growpart can often be run without stopping the server;
• pvresize can be run on an active LVM configuration;
• lvextend also typically does not require downtime;
• ext4 can be expanded while mounted;
• XFS can also be expanded online.

This means that on a small VPS, it is entirely possible to expand a disk without any noticeable downtime.

However, even in production, there are situations where it is better to schedule a maintenance window.

For example:

• The disk is almost full;
• The server is under heavy load;
• The database is actively writing large volumes of data;
• A complex LVM layout is in use;
• The partitions are arranged in a nonstandard layout;
• Partitions need to be moved or repartitioned;
• It is unclear exactly how the cloud provider applies the new size;
• The system will need to be rebooted.

Under these conditions, even an operation that technically supports online resizing becomes less predictable.

A maintenance window allows you to:

• Reduce the load;
• Stop particularly sensitive services;
• Verify the backup without time pressure;
• Perform the resize;
• Check the file system;
• Test the applications;
• Roll back if necessary.

In other words, a maintenance window is not always required, but it is often a sensible precaution for critical infrastructure.

Why You Should Back Up Before Modifying a Partition

You can also create a backup after resizing.

However, it will no longer protect against errors that may have occurred while modifying the partitions.

This is why a backup must exist before the first command that modifies the disk structure.

This is especially important before:

1. running growpart;
2. modifying the partition table;
3. running pvresize;
4. or performing operations on a logical volume.

Proper preparation may include:

• a virtual disk snapshot;
• a file backup;
• a database dump;
• recording the current layout using lsblk, fdisk -l, pvs, vgs, and lvs.

Snapshots and backups should not be considered completely interchangeable.

A snapshot provides a convenient way to quickly restore a disk to a previous state, while a separate backup of the database or user files may be more useful for partial recovery.

Before resizing a production system, you should at least know:

• where the backup is stored;
• how recent it is;
• what data it contains;
• how quickly the service can be restored.

Ultimately, the preparation process is fairly straightforward:

1. Identify the exact disk and partition.
2. Check the file system and LVM configuration.
3. Create a backup.
4. Record the original layout.
5. Schedule a maintenance window if necessary.
6. Only then should you proceed with the expansion.

This turns resizing from a potentially stressful operation into a routine, controlled procedure.

Conclusion

Increasing the size of a VPS disk does not always end with clicking Resize in the cloud provider’s control panel.

After resizing the virtual disk, check each layer in sequence to determine which one still has the old size: the disk itself, the partition, LVM, or the file system.

For a standard partition, the process is usually straightforward: Linux must detect the new disk size, then the partition is extended using growpart, and the file system is expanded using resize2fs for ext4 or xfs_growfs for XFS.

LVM requires several additional steps: first the partition is extended, then the Physical Volume, followed by the Logical Volume, and finally the file system.

The key is not to memorize a single universal command, but to understand the storage layout of the specific VPS. This makes it possible to quickly diagnose situations where lsblk already shows the new capacity but df -hT does not.

And, of course, you should have an up-to-date backup before making any changes to the disk layout. Extending storage is generally safe, but an error at the partition or LVM level can cost far more than the few minutes required to create a backup and verify the existing layout.

FAQ

Do I need to reboot the VPS after expanding the disk?

Not always.

In many cloud environments, Linux detects the new disk size immediately, and growpart, pvresize, resize2fs, and xfs_growfs can be run without rebooting.

If the disk still reports its previous capacity, try rescanning the device first or follow the specific provider’s instructions. A reboot is usually required only if the system does not detect the new size automatically or if the platform requires it.

Why does lsblk show the new size while df -h still shows the old size?

Because these commands report information at different levels.

lsblk may already detect the expanded disk or partition, while the file system on it remains at its original size.

For ext4, after expanding the partition, the following command is usually required: sudo resize2fs /dev/sda1

For XFS: sudo xfs_growfs /

After that, the new capacity should also appear in df -hT.

Can I use lvextend -r directly instead of running resize2fs separately?

Yes.

For example: sudo lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

The -r option instructs LVM to extend the file system automatically along with the logical volume. This functionality is supported by lvextend itself.

However, for manual troubleshooting, it is useful to understand the individual steps: pvresize → lvextend → file system expansion. This makes it easier to identify exactly which layer caused the problem.

What does +100%FREE mean in lvextend?

It instructs lvextend to allocate all remaining free space in the Volume Group to the selected Logical Volume. The official lvextend documentation explicitly describes this use case.

If a VG contains multiple logical volumes, it is better not to use +100%FREE automatically, but instead to decide in advance how much space to allocate to a specific LV.

Can XFS be grown by specifying the device name instead of the mount point?

Modern versions of xfs_growfs accept either the mount point or the block device of a mounted XFS file system, but in practice, the mount point is usually clearer and less ambiguous. The file system must be mounted while it is being grown.

For example: sudo xfs_growfs /

What should I do if growpart reports that the partition cannot be extended?

First, check:

   lsblk
sudo fdisk -l /dev/sda

Possible causes:

• The disk has not yet recognized its new size;
• The partition already occupies all available space;
• The free space is not immediately after the partition;
• The increase is below growpart’s minimum threshold.

growpart uses the DISK PARTITION-NUMBER syntax and extends the partition as far as the free space immediately following it allows.

Can XFS Be Shrunk After It Has Been Expanded?

Shrinking a file system is more complex than expanding it and is best treated as a separate task.

Even where shrinking is technically possible, it requires significantly greater caution. For a production server, it is safer to plan a data migration or a dedicated procedure in advance rather than attempting to “reverse” the commands in this guide.

Do I need to create a backup if growpart and file system expansion are performed online?

Yes.

Online resize support means that the operation can be performed without taking the file system offline, but it does not eliminate the risk of administrator error, disk failure, or selecting the wrong device.

A backup is necessary not because growpart or resize2fs are inherently dangerous, but because these operations directly modify the data storage structure.

Sources

1. Ubuntu Manpages — growpart
2. Linux Manual Pages — xfs_growfs(8)
3. Linux Manual Pages — pvresize(8)
4. Linux Manual Pages — lvextend(8)