# Use the extra disk space after an add-on

> Added disk but df shows the old size? Restart from the panel, or grow the partition and filesystem without a reboot. Tested on Ubuntu, Debian and AlmaLinux.

Source: https://rack4.io/help/use-added-disk-space · Updated: 2026-11-06

After you [add disk](https://rack4.io/help/add-ons#extra-disk), the quickest way to use it is to restart the server from the panel: the partition and filesystem grow by themselves as it boots. If you can't restart right now, you can grow them yourself while the server keeps running, in two commands.

## Why the space doesn't show up at once

Three layers sit on top of each other, and an add-on only grows the first one straight away:

1. **The virtual disk** (`/dev/vda`): grows shortly after the add-on is paid, while the server runs. `lsblk` shows the new size.
2. **The partition** on it (for example `/dev/vda1`): still the old size, so the new space sits unused after it.
3. **The filesystem** in that partition: also the old size. This is what `df -h` reports.

So straight after an add-on, `lsblk` shows a bigger disk while `df -h /` doesn't. That's expected; nothing is broken.

## The simple way: restart from the panel

Restart the server from its page in the panel. Our images run cloud-init at every boot, and its standard settings grow the root partition and filesystem to fill the disk. When the server is back, check:

```bash
df -h /
```

On our Debian 13 test server, which had gone from 40 to 50 GB, `df -h /` showed 50G after one restart, with nothing done by hand. If yours still shows the old size after a restart (for example because you changed cloud-init's settings, or the root filesystem is on LVM), use the steps below.

## Without a reboot

Run these on the server. First see where the root filesystem lives and what kind it is:

```bash
lsblk
findmnt -no SOURCE,FSTYPE /
```

The partition number isn't the same on every image, so read it from the output rather than copying someone else's. Our test servers showed:

| Image | `findmnt` printed | Disk | Partition |
|---|---|---|---|
| Ubuntu 24.04 | `/dev/vda1 ext4` | `/dev/vda` | `1` |
| Debian 13 | `/dev/vda1 ext4` | `/dev/vda` | `1` |
| AlmaLinux 10 | `/dev/vda4 xfs` | `/dev/vda` | `4` |

**Grow the partition**, with your own disk and partition number (a space between them):

```bash
sudo growpart /dev/vda 1
```

It answers with a line that starts `CHANGED: partition=1`. If it says `NOCHANGE`, the partition already fills the disk: check `lsblk` again in a minute, because the disk itself may not have grown yet.

**Then grow the filesystem.** Run only the one that matches the second word `findmnt` printed:

- `ext4`:

  ```bash
  sudo resize2fs /dev/vda1
  ```

  Use your own partition. It prints `The filesystem on /dev/vda1 is now … blocks long.`

- `xfs`: XFS is grown by its mount point, not the device:

  ```bash
  sudo xfs_growfs /
  ```

- `btrfs`:

  ```bash
  sudo btrfs filesystem resize max /
  ```

Both steps are safe on a running, mounted filesystem, and neither touches your files. Check the result:

```bash
df -h /
```

On our Ubuntu 24.04 test server, `/` went from 38G to 48G; on AlmaLinux 10, from 39G to 49G.

### When this doesn't apply

- `findmnt` shows a `/dev/mapper/…` device: that's LVM, which these steps don't cover. Restart from the panel, or grow the physical volume, logical volume and filesystem with your own LVM tools.
- `growpart: command not found`: install it with `apt install cloud-guest-utils` (Ubuntu, Debian) or `dnf install cloud-utils-growpart` (AlmaLinux, Rocky Linux, Fedora), or restart from the panel instead.
- You added a second filesystem or a swap partition at the end of the disk yourself: the root partition can't grow past it. Restarting won't help either; that layout is yours to rearrange.

## Snapshots and backups

- Reverting to a [snapshot](https://rack4.io/help/snapshots) taken before the disk grew keeps the bigger disk, but brings back the snapshot's smaller partition and filesystem. Restart from the panel, or repeat the steps above.
- The same goes for restoring an [off-site backup](https://rack4.io/help/off-site-backups) made before the disk grew.
- A disk can't be made smaller again once it's grown, so add what you need rather than a lot more.

We tested this on 6 November 2026 on Rack4 servers built from our Ubuntu 24.04, Debian 13 and AlmaLinux 10 images, each grown from 40 to 50 GB with the disk add-on. The btrfs line comes from btrfs's own tools and wasn't part of that test.