Skip to content
Fedora Community Docs
Fedora
Docs networkNetwork
Search Fedora

    Browse this documentation

    Storage on Fedora: btrfs subvolumes, mounts and capacity checks

    Fedora’s default install has not been “one ext4 root partition” for a long time. The F45 Cloud image measured here is btrfs with zstd compression and four subvolumes. Without that model, df output never looks right.

    The measured layout

    Section titled “The measured layout”
    Terminal window
    lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
    NAME    SIZE FSTYPE  MOUNTPOINTS
    sda      20G
    ├─sda1    2M
    ├─sda2  100M vfat    /boot/efi
    └─sda3 19.9G btrfs   /var
                         /home
                         /boot
                         /

    The four matching lines in /etc/fstab:

    Terminal window
    grep -vE "^#|^$" /etc/fstab
    UUID=d04d5cb8-... /      btrfs compress=zstd:1,defaults,subvol=root  0 1
    UUID=d04d5cb8-... /boot  btrfs compress=zstd:1,subvol=boot           0 0
    UUID=d04d5cb8-... /home  btrfs compress=zstd:1,subvol=home           0 0
    UUID=d04d5cb8-... /var   btrfs compress=zstd:1,subvol=var            0 0

    Three things to take away:

    What you seeWhat it means
    the same UUID mounted four timesnot four partitions but four subvolumes of one filesystem
    subvol=the subvolume name, not a path
    compress=zstd:1transparent compression, applied on write, undone on read

    btrfs subvolumes share one space pool: root, boot, home and var all live on the same 19.9 GiB filesystem, so df reports the same capacity for each mountpoint

    Why df looks wrong

    Section titled “Why df looks wrong”
    Terminal window
    df -hT / /boot
    Filesystem     Type   Size  Used Avail Use% Mounted on
    /dev/sda3      btrfs   20G  2.1G   18G  11% /
    /dev/sda3      btrfs   20G  2.1G   18G  11% /boot

    btrfs subvolumes share one space pool, so every row reports the whole filesystem. Filling /var fills the disk; there is no “this subvolume still has room”.

    df also estimates Avail on btrfs. For a better view:

    Terminal window
    sudo btrfs filesystem usage /
    sudo btrfs subvolume list /
    ID 256 gen ... path root
    ID 257 gen ... path boot
    ID 258 gen ... path home
    ID 259 gen ... path var

    Measured on an installed F45: lsblk shows sda3 as 19.9G btrfs carrying /var, /home, /boot and /; df -hT reports 20G at 11% for both / and /boot; btrfs subvolume list shows root, boot, home, var and snapshots

    Capacity investigation order

    Section titled “Capacity investigation order”
    Terminal window
    df -h /                    # 1) filesystem level
    df -i /                    # 2) inodes (btrfs can exhaust them too)
    sudo btrfs filesystem usage /   # 3) real usage and unallocated space
    du -xh --max-depth=1 / | sort -h | tail -10   # 4) who is using it
    sudo journalctl --disk-usage                   # 5) logs
    sudo podman system df                          # 6) containers and images

    Space not coming back after a delete is the most common confusion — a process still holds the deleted file:

    Terminal window
    sudo lsof +L1 | head -10

    Adding a disk

    Section titled “Adding a disk”
    Terminal window
    lsblk                                  # confirm the new name (sdb)
    sudo mkfs.xfs /dev/sdb                 # or btrfs / ext4
    sudo mkdir -p /data
    sudo mount /dev/sdb /data
    sudo blkid /dev/sdb                    # get the UUID

    Use the UUID in /etc/fstab, never /dev/sdb — device names change with plug order:

    UUID=<new> /data xfs defaults 0 0

    Test before rebooting:

    Terminal window
    sudo mount -a     # errors surface immediately
    findmnt /data
    Section titled “Related pages”