this post was submitted on 08 Oct 2025
40 points (97.6% liked)

Linux

58885 readers
468 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 6 years ago
MODERATORS
 

Edit: Solved!

Unfortunately I'm not sure exactly what fixed it, because I was running btrfs commands like a madman. Some combination of the following caused my 100GB labelled as UNREACHABLE to turn into UNUSED, which allowed that space to be written to as normal:

sudo btrfs balance start -v /

sudo btrfs filesystem defrag -v /

sudo btrfs filesystem defrag -v -r /

Also the tool btdu was incredibly helpful!


One of my linux boxes ran out of disk space, which surprised me, because it definitely didn't have that much stuff on it. When I check with df it says I have used 212GB on my / path:

$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       227G  212G  5.2G  98% /

So, I tried to use du to see if maybe a runaway log file was the cause, but this says I have only used 101GB on my / path (this is also more in-line with how much space I expected to be used):

$ du -h | sort -h
...
101G    /

Using those commands with sudo outputs the same sizes.

My filesystem is Btrfs, I've tried the suggestion to use btrfs balance start ... but this actually INCREASED my disk usage to 99% lol

So my question is... what on earth is using the remaining 111GB?? Why can I not see it in du?

you are viewing a single comment's thread
view the rest of the comments
[–] Kruulos@sopuli.xyz 13 points 4 days ago (1 children)

I had the exact same problem on one of my virtual boxes. The problem baffled me for two years and I just added more space to the box a few times to fight it as I couldn't solve the issue. It wasn't the inodes, deleted but open files or anything common like that.

The problem was my mounts. I had occasionally failing mounts combined with crontabs that accessed and wrote data to those mounts. Do you know what happens when you accidentally wrote let's say 200gb data to /mnt/a and then later mount a drive over that mount point? It magically 'disappears' as you'd exclude that mount from the calculations.

Might be you don't have anything mounted and none of the above is useful to you. But this solved my issue and it's quite curious and silly. Just set up mount points to not be writeable and problem went away.

[–] Jozzo@lemmy.world 3 points 4 days ago* (last edited 3 days ago)

Interesting, this could be it? I haven't configured any mounts on this device yet, but when I tried one of the other suggestions from this thread and use btdu, I get this error:

$ ./btdu -x /
Fatal error: The mount point you specified, "/", is not the top-level btrfs subvolume ("subvolid=5,subvol=/").
It is the btrfs subvolume "subvolid=256,subvol=/@rootfs".
Please specify the path to a mountpoint mounted with subvol=/ or subvolid=5.
E.g.: mkdir /mnt/sda1 && mount -o subvol=/ /dev/sda1 /mnt/sda1 && ./btdu /mnt/sda1

Note that the top-level btrfs subvolume ("subvolid=5,subvol=/") is not the same as the root of the filesystem ("/").

I'm fairly new to the workings of Btrfs so this is jibberish to me right now, but I'll look into it more

EDIT: Nevermind! I was just using the tool wrong. I needed to mount my btrfs "sub-volume" then do the scan against that:

sudo mkdir -p /mnt/btdu

sudo mount -o subvolid=5 /dev/sda1 /mnt/btdu

sudo ./btdu /mnt/btdu