DF -h command shows figures different from Gparted and cant increase /dev/mapper/fedora-root

Ask Fedora
1

Hi, I have a fedora 43 VM where it has 1 83GB disk. I always had between 12-15 GB of free space but all of a sudden I started seeing only 4 Gb free.

I triggered Gparted even as root, where I see almost 15 GB of free space but cant resize it.

image
image791×534 111 KB

whereas when I issue

df -h

I get different information

~/$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/fedora-root 68G 64G 3.4G 95% /
devtmpfs 3.3G 0 3.3G 0% /dev
tmpfs 3.3G 12K 3.3G 1% /dev/shm
tmpfs 1.4G 5.5M 1.4G 1% /run
tmpfs 3.3G 100K 3.3G 1% /tmp
tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-journald.service
/dev/sda1 974M 288M 620M 32% /boot
tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-resolved.service
tmpfs 676M 180K 676M 1% /run/user/60579
tmpfs 676M 144K 676M 1% /run/user/0
tmpfs 676M 176K 676M 1% /run/user/1000

2

You’re using the Logical Volume Manager (LVM) partitioning scheme.

Check to free space by executing vgdisplay (sample output below) and look for the ‘Free PE’ row, That value times the ‘PE Size’ is the free space available to the LVMs in your Volume Group (VG).

— Volume group —
VG Name               fedora_localhost-live
System ID
Format                lvm2
Metadata Areas        1
Metadata Sequence No  3
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                2
Open LV               2
Max PV                0
Cur PV                1
Act PV                1
VG Size               57.41 GiB
PE Size               4.00 MiB
Total PE              14697
Alloc PE / Size       7680 / 30.00 GiB
Free  PE / Size       7017 / 27.41 GiB
VG UUID               lHolBz-wTdT-326W-dmuZ-iZoX-VMr9-zJGfXF

Details about your logical volumes can be seen with lvdisplay

If you want the additional space, you’ll need to extend the logical volume for your root filesystem and extend the filesystem.

something like:

lvextend -L 82GB -r /dev/mapper/fedora-root

‘-L’ specifies the new size of the logical volume (LV)/partition, and ‘-r’ extends the filesystem on the LV.

More information about LVM is available here, here, here, here and here

HTHAL.

3

I would be curious to know what is taking up the space before considering extending the disk.

Logs – journalctl --disk-usage

Largest directories – sudo du -xh / --max-depth=1 2>/dev/null | sort -hr

4

@rubirod1200 Here is the ouptut

Archived and active journals take up 117.8M in the file system.

and here is the output for

$ sudo du -xh / --max-depth=1 2>/dev/null | sort -hr
63G /
27G /var
18G /usr
11G /home
5.5G /root
2.4G /opt
37M /etc
76K /srv
0 /mnt
0 /media
0 /.cache
0 /afs

5

I would be curious to know what is taking up the space before considering extending the disk.

That’s definitely a good idea. And should definitely be looked at.

Although the title of this thread is:

DF -h command shows figures different from Gparted

And the df -h vs. gparted figures are different because the lvm Volume Group has free physical extents (PEs) that aren’t assigned to any Logical Volumes.

and cant increase /dev/mapper/fedora-root

and since it is LVM that’s in use here. increasing the size of /dev/mapper/fedora-root needs to be done with the lvextend command.

As for what might be eating up space:

/var and /home look like likely candidates for chewing up that space.

Perhaps podman/docker containers and/or flatpaks in /var and/or dnf caches (dnf5 clean all; dnf4 clean all ) and potentially log files other than the journal (/var/log/httpd/*), etc.

Maybe try du -xh /var 2>/dev/null | sort -h

All manner of user files (and/or the above too) in /home?

and du -xh /home 2>/dev/null | sort -h

6

Thanks Rectangular, I have kubernetes on this VM, I executed this statement, yes I see huge files, especially in the cache, such as

1013M /var/lib/docker/overlay2/4a86fd7f4ebd18b19fccdf78d4cb5737c0a41512f766b20067889cd9512584cd/diff/opt/mssql/lib
1.1G /var/lib/docker/overlay2/4a86fd7f4ebd18b19fccdf78d4cb5737c0a41512f766b20067889cd9512584cd
1.1G /var/lib/docker/overlay2/4a86fd7f4ebd18b19fccdf78d4cb5737c0a41512f766b20067889cd9512584cd/diff
1.1G /var/lib/docker/overlay2/4a86fd7f4ebd18b19fccdf78d4cb5737c0a41512f766b20067889cd9512584cd/diff/opt
1.1G /var/lib/docker/overlay2/4a86fd7f4ebd18b19fccdf78d4cb5737c0a41512f766b20067889cd9512584cd/diff/opt/mssql
1.2G /var/log
1.3G /var/lib/docker/overlay2/45bbfb51cdee4c73e7d59a352a8f69f5456be50fb7c40df8bff170ca88168615/diff/usr/lib
1.3G /var/lib/docker/overlay2/f64fc39f9dfbe2a16dac2ff3d5366f9da630c512a3a7135232221ecffd97adf6/diff/home/zap/.gradle/caches
1.6G /var/lib/docker/overlay2/45bbfb51cdee4c73e7d59a352a8f69f5456be50fb7c40df8bff170ca88168615
1.6G /var/lib/docker/overlay2/45bbfb51cdee4c73e7d59a352a8f69f5456be50fb7c40df8bff170ca88168615/diff
1.6G /var/lib/docker/overlay2/45bbfb51cdee4c73e7d59a352a8f69f5456be50fb7c40df8bff170ca88168615/diff/usr
1.7G /var/lib/docker/overlay2/f64fc39f9dfbe2a16dac2ff3d5366f9da630c512a3a7135232221ecffd97adf6/diff/home/zap/.gradle
1.8G /var/lib/docker/overlay2/f64fc39f9dfbe2a16dac2ff3d5366f9da630c512a3a7135232221ecffd97adf6/diff/home
1.8G /var/lib/docker/overlay2/f64fc39f9dfbe2a16dac2ff3d5366f9da630c512a3a7135232221ecffd97adf6/diff/home/zap
2.2G /var/cache/PackageKit/43/metadata/updates-43-x86_64/packages
2.2G /var/lib/docker/overlay2/f64fc39f9dfbe2a16dac2ff3d5366f9da630c512a3a7135232221ecffd97adf6
2.2G /var/lib/docker/overlay2/f64fc39f9dfbe2a16dac2ff3d5366f9da630c512a3a7135232221ecffd97adf6/diff
2.3G /var/cache/PackageKit/43/metadata/updates-43-x86_64
2.6G /var/cache/PackageKit/43/metadata
2.7G /var/cache/PackageKit
2.7G /var/cache/PackageKit/43
3.1G /var/cache
19G /var/lib/docker
19G /var/lib/docker/overlay2
23G /var/lib

7

You might have some no-longer-used Docker stuff there - you could try pruning to free up space?

8

I did and recovered almost 8 GB. So many thanks for your help