You bumped your VPS plan up a tier, or added extra block storage, specifically because you were running low on disk. The provider panel confirms it: the disk is bigger now. You log back into the server, run df -h, and—nothing's changed. Same old size, same low-space warning. This trips up almost everyone the first time, and the fix is quick once you know the three separate places Linux tracks "how big is this disk."
The Symptom: Bigger Disk in the Panel, Same Size in Linux
Growing a VPS disk from your hosting dashboard only resizes the virtual block device the hypervisor hands to your VM. It does not touch the partition table inside that device, and it does not touch the filesystem sitting on top of the partition. Linux has to be told about the extra space at each of those layers before anything can actually use it. Skip a layer and df -h keeps reporting the old total no matter how much bigger the underlying disk got.
Run this first to confirm the kernel even sees the new capacity:
lsblk
If lsblk still shows the old size, the block device rescan hasn't happened yet — more on that below. If it shows the new, larger total against /dev/sda or /dev/vda but your partition (/dev/sda1, or a logical volume) is still the old size, you're in the normal case: the disk grew, the partition and filesystem didn't.
Two Setups, Two Fixes
How you extend the partition depends on whether the server uses a plain partition or LVM (Logical Volume Manager). Check with:
lsblk -f
If you see entries like vg-root or ubuntu--vg-ubuntu--lv, you're on LVM. If you just see a plain partition like sda1 mounted straight to /, you're not.
Case A: Plain Partition (No LVM)
Install cloud-guest-utils if growpart isn't already on the box, then extend the partition to fill the new disk space:
sudo apt install cloud-guest-utils -y # Debian/Ubuntu
sudo yum install cloud-utils-growpart -y # AlmaLinux/CentOS/RHEL
sudo growpart /dev/sda 1
That grows partition 1 on /dev/sda to consume all the newly available space. Then jump to the filesystem step below.
Case B: LVM
LVM adds a layer, so there are two commands instead of one. First, tell the physical volume it has more room to work with:
sudo pvresize /dev/sda3
(Substitute the actual partition holding your LVM physical volume — check with pvs if you're not sure.) Then extend the logical volume to use that new space:
sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
-l +100%FREE tells it to grab every bit of unallocated space in the volume group, which is almost always what you want right after a disk grow. Find your logical volume's exact path with lvs if the name above doesn't match yours.
Step: Grow the Filesystem
Resizing the partition or logical volume doesn't resize the filesystem sitting inside it — that's a separate command, and it depends on whether you're running ext4 or XFS.
| Filesystem | Command |
|---|---|
| ext4 | sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv (or the partition path, e.g. /dev/sda1) |
| XFS | sudo xfs_growfs / (run against the mount point, not the device) |
Both of these run safely on a live, mounted filesystem — no unmounting, no downtime, no reboot required. Confirm the new size landed:
df -h /
You should now see the full new capacity reflected against your root filesystem.
If lsblk Still Shows the Old Size
Occasionally the kernel doesn't notice the resized virtual disk until you nudge it. Try a rescan of the SCSI bus without rebooting:
echo 1 | sudo tee /sys/class/block/sda/device/rescan
If that doesn't pick it up, check your provider's control panel to make sure the resize operation actually completed — some providers process disk resizes asynchronously and it can take a minute or two after you click confirm. As a last resort, a reboot will always pick up the new size, but it's rarely necessary.
Common Mistakes
- Running resize2fs on a device that's actually XFS. It'll fail with a "bad magic number" error. Check the filesystem type first with
df -T /. - Forgetting the LVM layer exists. Running
growpartalone on an LVM setup extends the partition but leaves the physical volume, volume group, and logical volume all still reporting the old size —pvresizeandlvextendare not optional here. - Targeting the wrong partition number. On a fresh cloud image, the LVM physical volume is often the third partition, not the first — double-check with
lsblkbefore runningpvresize. - Shrinking instead of growing. None of the commands above work in reverse. Shrinking a filesystem safely requires unmounting it, and doing it wrong is a fast way to lose data — that's a separate, much more careful procedure.
Prevention: Make the Next Resize a Non-Event
A few habits make this painless every time instead of a fire drill:
- Take a snapshot before resizing the disk. It's cheap insurance, and if the resize operation itself hiccups on the provider's end, you've got a clean rollback point.
- If you provisioned the VPS yourself, set it up with LVM from day one, even if you don't need the flexibility yet. Growing an LVM volume later is a two-command job; converting a plain partition to LVM after the fact is not.
- Watch disk usage before it becomes an emergency — a simple cron job that emails you when
dfcrosses 80% buys you time to resize calmly instead of resizing while a site is already down. - Document the exact device and volume names for your server (in a README, a wiki page, wherever) so the next resize doesn't start with ten minutes of
lsblkarchaeology.
Frequently Asked Questions
Do I need to reboot the VPS to see the extra disk space?
Almost never. Growing the partition (or LVM volume) and the filesystem can both be done live on a mounted, running system. A reboot is only a fallback if the kernel isn't picking up the resized block device through a SCSI rescan.
How do I know if my server uses LVM or a plain partition?
Run lsblk -f. If you see volume names like vg-root or something ending in -lv under a partition, that's LVM. A plain setup shows the partition (like sda1) mounted directly to / with no volume group in between.
I ran resize2fs and got "resize2fs: Bad magic number in super-block." What happened?
You're almost certainly on XFS, not ext4. Check with df -T / and use xfs_growfs / instead — it takes the mount point as its argument, not a device path.
Can I shrink a disk the same way, just in reverse?
No. None of these commands are reversible in that sense. Shrinking a live filesystem safely typically requires unmounting it (often by booting from a rescue image), and doing it out of order risks data loss. If you need to reclaim disk space, look at clearing unused files instead of shrinking the volume.
Will this work the same way on any VPS provider?
The Linux-side commands (growpart, pvresize, lvextend, resize2fs, xfs_growfs) are the same regardless of provider, since they operate entirely inside your VM. What differs is how you actually trigger the disk size increase on the hypervisor side — that part is always done from your provider's control panel or API before you touch the terminal.
