Free disk space remains the same, regardless of any changes made to the system

[morsontologica]

System details

Omarchy v3..1.7

What's wrong?

My machine always has 43.1gb of free disk space now, this is what I get from Nautilus (although it does say some content is unreadable) and from running df -h /

I believe this issue happened before today's update, I noticed tubearchivist stopped working last night while I was away from home, this morning the docker logs showed disk space as the reason, and this was when I realized what was happening. Tried deleting a few large files just to check, no change

[morsontologica]

I've just realized it's probably connected to snapper, the .snapshots folder and /dev/mapper/root

~ ❯ df -h
Filesystem        Size  Used Avail Use% Mounted on
dev               7.8G     0  7.8G   0% /dev
run               7.8G  3.4M  7.8G   1% /run
efivarfs          128K   21K  103K  17% /sys/firmware/efi/efivars
/dev/mapper/root  464G  421G   42G  92% /
tmpfs             7.8G   62M  7.8G   1% /dev/shm
tmpfs             1.0M     0  1.0M   0% /run/credentials/systemd-networkd.service
tmpfs             7.8G   16M  7.8G   1% /tmp
/dev/mapper/root  464G  421G   42G  92% /home
/dev/mapper/root  464G  421G   42G  92% /var/cache/pacman/pkg
/dev/mapper/root  464G  421G   42G  92% /var/log
/dev/nvme0n1p1    2.0G  134M  1.9G   7% /boot
/dev/sda1         1.8T  1.8T  7.2G 100% /run/media/rubinstein/Hitachi
/dev/sdb1         916G  819G   51G  95% /run/media/rubinstein/Seagate
tmpfs             1.6G  144K  1.6G   1% /run/user/1000
tmpfs             1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
tmpfs             1.0M     0  1.0M   0% /run/credentials/systemd-resolved.service


~ ❯ df -h /
Filesystem        Size  Used Avail Use% Mounted on
/dev/mapper/root  464G  421G   42G  92% /


~ ✗ sudo df -h /.snapshots
Filesystem      Size  Used Avail Use% Mounted on
-               464G  421G   42G  92% /.snapshots

[maxguzenski]

use "dust" to see where is your large files. You can delete snapshots with "sudo snapper list" and "sudo snapper delete [id]" .

By default omarchy keep 5 snapshots, you may have large files that are changing between snapshots.

[Gr44y]

I can see the snapshots and the ID but when i try to delete it, it says "Invalid snapshot"

[morsontologica]

@maxguzenski the problem isn't lack of space, I think you might have misunderstood me. Just deleted a 119gb file and my machine still claims to only have 43.1gb free disk space.

My machine incorrectly lists my free disk space as whatever the size of /.snapshots folder is, if that makes any sense at all

[maxguzenski]

Maybe I'm wrong, but:
You have 5 (by default) snapshot pointing to those large files. You delete those files at current. But all old snapshot still point to it, that means that your file will NOT be real delete and you will not get that space back and you cant use that space to other files.

[morsontologica]

@maxguzenski I understand what you mean now. Thanks, I'll try it. What you said makes total sense

[maxguzenski]

You can set snapper to exclude some directories from snapshot, like docker logs/image/volumes. I dont know how exactly omarchy config snapper, but you can change it if necessary.

[morsontologica]

@maxguzenski thanks a million, it was snapper related indeed. After removing all but the current snapshot, I still had the same issue. After a bit of reading I realized that despite snapshots having been deleted, the related subvolumes were still present. Deleted the relevant ones, and free disk space was reclaimed

sudo btrfs subvolume list / | grep snapshot
ID 263 gen 44555 top level 257 path @home/.snapshots 
ID 313 gen 30724 top level 262 path .snapshots/25/snapshot 
ID 314 gen 32234 top level 263 path @home/.snapshots/26/snapshot 
ID 316 gen 35729 top level 263 path @home/.snapshots/27/snapshot 
ID 318 gen 36827 top level 263 path @home/.snapshots/28/snapshot 
ID 320 gen 40948 top level 263 path @home/.snapshots/29/snapshot 
ID 321 gen 42079 top level 263 path @home/.snapshots/30/snapshot 
ID 323 gen 44555 top level 263 path @home/.snapshots/31/snapshot

[jdlewin]

pretty sure we're having the same issue that you were @morsontologica. would you expand a bit on how you identified the appropriate directories to delete and the commands you used to do so

[morsontologica]

Sure, here's what I did:

sudo snapper list
sudo snapper delete (ID)

I deleted every snapshot but "0"

sudo btrfs subvolume list / | grep snapshot

sudo btrfs subvolume delete /home/.snapshots/5/snapshot
sudo btrfs subvolume delete /.snapshots/5/snapshot

I deleted every subvolume with a number after the .snapshots folder

[redredkrovy]

Thank you! I just ran into this problem during an update. I couldn't even get to the desktop environment. Thank god for snapshots but also screw snapshots. LOL
I ended up recovering over 400gb of space.

[emiara]

My disk got completely filled up and I couldn't even get to the desktop. Deleted 200 gb of local llms from ollama and, like a horrormovie, the gbs were still there. Took me longer then id like to admit to realize it was snapshots related. Thought I had been zipbombed like the good old days!