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

Linux

58885 readers
489 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
nooter692@lemmy.ml
AgreeableLandscape@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
40
(SOLVED) Where did all my space go? (lemmy.world)
submitted 4 days ago* (last edited 1 day ago) by Jozzo@lemmy.world to c/linux@lemmy.ml
21 comments fedilink hide all child comments
 

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?

top 21 comments
sorted by: hot top controversial new old
[–] utopiah@lemmy.ml 23 points 4 days ago* (last edited 4 days ago) (1 children)

I typically investigate with ncdu which gives very useful visualization like :

***
/home/fabien/Prototypes/esphome/.esphome ----------------------------------------------------------------------------------------------------------------
                                     /..
    3.1 GiB [######################] /platformio
  218.1 MiB [#                     ] /build
   28.0 KiB [                      ] /idedata
    8.0 KiB [                      ] /storage

and let's you iterate. Here for example you'd go into platformio and get another view, press d to delete files or directories that aren't needed anymore if it's a stale project e.g. node_modules. Go back, etc.

So yes, warmly recommended, both on desktop and remote servers. It's way easier IMHO that du -sh ./directory then cd, rinse and repeat. It's also way WAY faster then GUI equivalents ... because you navigate and take action, e.g. delete, with your keyboard.

All that being said, if it's about your filesystem rather than your files, it probably won't help much. I don't know enough about btrfs to help unfortunately.

[–] Jozzo@lemmy.world 6 points 4 days ago

ncdu

Oh this one is very cool! Unfortunately it also only shows the same 101GB being used:

ncdu 1.22 ~ Use the arrow keys to navigate, press ? for help                                                                                                                                  
***
/ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   93.1 GiB [###########################] /home                                                                                                                                               
    6.5 GiB [#                          ] /usr
  790.4 MiB [                           ] /var
  173.0 MiB [                           ] /boot
   12.8 MiB [                           ] /etc
    1.7 MiB [                           ] /root
    1.3 MiB [                           ] /run
   44.0 KiB [                           ] /tmp
@   4.0 KiB [                           ]  initrd.img.old
@   4.0 KiB [                           ]  initrd.img
@   4.0 KiB [                           ]  vmlinuz.old
@   4.0 KiB [                           ]  vmlinuz
@   4.0 KiB [                           ]  lib64
@   4.0 KiB [                           ]  sbin
@   4.0 KiB [                           ]  lib
@   4.0 KiB [                           ]  bin
.   0.0   B [                           ] /proc
    0.0   B [                           ] /sys
    0.0   B [                           ] /dev
    0.0   B [                           ] /media
e   0.0   B [                           ] /srv
e   0.0   B [                           ] /opt
e   0.0   B [                           ] /mnt
[–] codemichael@lemmy.world 19 points 4 days ago (1 children)

BTRFS snapshots world be my first guess. ‘sudo btrfs subvolume list /‘

[–] Jozzo@lemmy.world 2 points 4 days ago

There is one listed: ID 256 gen 137604 top level 5 path @rootfs Looks like it is just my filesystem though?

[–] Corngood@lemmy.ml 16 points 4 days ago (1 children)

btdu is an excellent tool for finding out what's taking up space in btrfs

[–] Jozzo@lemmy.world 5 points 3 days ago (3 children)

Legend! It found a second filesystem named "UNREACHABLE":

It looks like an exact duplicate of my main filesystem "/@rootfs", I'm guessing this is why my disk space filled up. Do you know how I'd go about removing the duplicate? (If it's safe to do so)

[–] Oinks@lemmy.blahaj.zone 2 points 2 days ago* (last edited 2 days ago) (1 children)

I'm not a btrfs expert but AFAIK high unreachable space usage is usually a result of fragmentation. You might want to defragment the filesystem and see if that helps.

I will note that btrfs makes estimations of used/available space very difficult by design, and you especially can not trust what standard UNIX tools like df and du tell you about btrfs volumes. Scripting around du or using ncdu will not help here in any way. You might want to read this kernel.org wiki article as well as the man pages for the btrfs tools (btrfs(8) and particularly btrfs-filesystem(8)), which among other things provide versions of df and du that actually work, or at least they do most of the time instead of never.

[–] Jozzo@lemmy.world 1 points 1 day ago

Looks like some combination of defragging & balancing has done the trick! The space that was previously marked UNREACHABLE is now UNUSED, and my disk space is back to normal:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       227G  105G  103G  51% /

Thanks for the wiki link, Btrfs is new to me and I've definitely got some learning to do

[–] Corngood@lemmy.ml 1 points 2 days ago

Strange, I've never seen that. Have you rebooted the system to make sure it has nothing to do with open files?

I did find one thread that seems related:

https://www.reddit.com/r/btrfs/comments/lip3dk/unreachable_data_on_btrfs_according_to_btdu/

[–] BCsven@lemmy.ca 3 points 3 days ago (1 children)

There could be btrfs stuff I'm not aware of, but on a file system structure level, do you have a separate drive for booting and then another you added and mounted separately? Or did you install Linux over another install and changed partitions used? The reason I'm asking is you could have a whole drive of data under a folder and then later mount another partition or drive to that same folder. Linux will show you the mounted folder contents, but the original is not visible until you unmount your Mount point. The data is still there. So drive can be full, even though contents look smaller.

I can't say its that for sure, but it has tripped people up before.

But could be btrfs cleanup needs looking at.

[–] Jozzo@lemmy.world 2 points 3 days ago (2 children)

Just one drive, it was a clean Linux install with no funky stuff going on. I'll have to look into Btrfs cleanup more, last time I did it the disk just filled up even more

[–] magikmw@piefed.social 1 points 3 days ago

I sometimes use btrf assistant, it's a gui helper for btrfs, shows some helpful hints, there's balancing, scrubbing, snapshot cleanup. I should learn more about it all, but it helped a ton with figuring out what's going on with all my space.

[–] BCsven@lemmy.ca 1 points 3 days ago

Yeah, I haven't dealt with that much since OpenSUSE has all the cleanup and maintenance scheduled.

Is your whole drive BTRFS even your /Home on same partition? The BTRFS subvolumes share a pool if setup as one, and filling up home subvolume also fills up your system subvolume, since its shared.

[–] 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

[–] danielquinn@lemmy.ca 6 points 3 days ago* (last edited 3 days ago) (2 children)

The bit of information you're missing is that du aggregates the size of all subfolders, so when you say du /, you're saying: "how much stuff is in / and everything under it?"

If you're sticking with du, then you'll need to traverse your folders, working downward until you find the culprit folder:

$ du /*
(Note which folder looks the biggest)
$ du /home/*
(If /home looks the biggest)

... and so on.

The trouble with this method however is that * won't include folders with a . in front, which is often the culprit: .cache, .local/share, etc. For that, you can do:

$ du /home/.*

Which should do the job I think.

If you've got a GUI though, things get a lot easier 'cause you have access to GNOME Disk Usage Analyzer which will draw you a fancy tree graph of your filesystem state all the way down to the smallest folder. It's pretty handy.

[–] Jesus_666@lemmy.world 9 points 3 days ago

GUI disk space analyzers are absolutely amazing.

For those who prefer KDE and/or donut graphs, Filelight has you covered.

[–] Duke_Nukem_1990@feddit.org 4 points 3 days ago

Bookmarked! Thanks!

[–] gkaklas@lemmy.zip 5 points 4 days ago

You could try sudo dua i /:

  1. sudo: Without it, it might miss some files
  2. dua: helps a lot with browsing directories and checking for their contents
[–] SomGye@sh.itjust.works 4 points 4 days ago

I agree with the other suggestions, though if you want a quick and easy GUI tool, I use Filelight

[–] scott@lem.free.as 2 points 4 days ago

This was a question we used to ask during job interviews.

You might want to look into your running processes to see if any still have file handles open for the items that have been removed. lsof can be used to find such things.

The shortcut would be to reboot.