Hi, I’m having trouble with this one Tumbleweed install… I have TW in several computers but only on my wife’s laptop this is happening, specifically it keeps running out of space. Gnome tells her it’s running out of space and Chrome will just shut down out of the blue. Then I check the flatpak cache and that’s what seems to be eating up space - I delete it and then it’s fine again for a while. Until it happens again.
I’ve heard btrfs can be a PITA when it comes to space management, and I have accordingly set up more stringent snapper controls and btrfs maintenance (like daily defrag and balance etc), and even a startup script to remove the flatpak cache stuff. On the other hand, I think she doesn’t log out / turn off her computer for days / weeks, and I think it’s kind of weird to have to tell her to do that when I do basically the same thing and I never have an issue. Her system has a 240GB SSD and there aren’t that many files and apps installed. Again, I have flatpaks in my other installations, one of which has even less root SSD space, and this never ever happens.
Should I just… Reinstall the system with ext4? Or is there something else I could/should try first?
You can start by looking at what snapshots are on the drive. Try:
sudo snapper list
You can probably delete snapshots older than a few days ago. I usually manually do some cleanup after running updates - there’ll be two snapshots made (at least) - a ‘pre’ and a ‘post’. Those can be deleted in pairs.
Showing us the output of:
sudo fdisk -l
Also will help us see what the partition structure is and how much space is allocated.
btrfs is fine, but depending on how much space is allocated to the root partition, the config might need some tweaking.
I’ve been running Tumbleweed for years on a 250GB system drive, and it barely uses a quarter of that space with no special maintenance necessary. (I don’t use Flatpaks, though.) I would try lowering snapper’s space limit and/or the number of snapshots to keep and see if that gets the problem under control before reformatting the drive.
@petersonsilva Hi, so how are the flatpaks installed, as system or user? If system then it’s likely being included in the snapshots. Suggest you look at installing as user if this is the case…
Thank you all so much for the responses! I’ll address them in order:
@hendersj ‘sudo snapper list’ yields 6 snapshots: current, the first root filesystem, and 2 pre-post pairings from updates; together they occupy no more than 4 GB of space. I remember a few weeks ago I reduced the number of snapshots the system is supposed to keep so I knew this wouldn’t likely be the problem if I experienced the issue again.
‘sudo fdisk -l’ yields this:
Disco /dev/sda: 223,57 GiB, 240057409536 bytes, 468862128 setores
Modelo de disco: ADATA SU650
Unidades: setor de 1 * 512 = 512 bytes
Tamanho de setor (lógico/físico): 512 bytes / 512 bytes
Tamanho E/S (mínimo/ótimo): 512 bytes / 512 bytes
Tipo de rótulo do disco: gpt
Identificador do disco: 61364546-53EC-42B5-82EB-45F3B5E3030F
Dispositivo Início Fim Setores Tamanho Tipo
/dev/sda1 2048 1050623 1048576 512M Sistema EFI
/dev/sda2 1050624 464666623 463616000 221,1G Linux sistema de arquivos
/dev/sda3 464666624 468862094 4195471 2G Linux swap
@amiya “I would try lowering snapper’s space limit and/or the number of snapshots to keep and see if that gets the problem under control before reformatting the drive” - Unfortunately I’ve already done that
@myswtest no, (one of) the system one(s), found in: /var/lib/flatpak/repo/tmp/
This specific place had tons and tons of GB used and I could not for the life of me found online what they were for - I could only find people telling others with similar issues that it was ok to delete the flatpak-cache-* files found inside this dir.
@malcolmlewis they are installed as system. Is there a way to just change this without reinstalling the apps - especially without losing their settings? I wonder if it’s going to help much though if the same apps keep producing the horrendous amount of cache they have in the past. Is there a way to check how much space each flatpak is individually taking for their cache?
Thanks for the followup. I just checked that path’s content. It’s empty.
I then fired up four apps installed as Flatpaks and did a little bit of work in each, then checked that …/tmp/* path … still empty.
Or course, my Flatpaks are not installed as system-wide, but user specific (while logged in as the user, using Discover). Even so, the Flatpak cache path in the user’s home sub-dir still has an insignificant size, about 10mb.
Maybe ask your wife which apps she uses most, then start each one up individually (not all at once), then monitor disk usage over time. There could be a “rogue” app with some odd disk usage leak.
Thank you! Honestly from her app list the one she uses basically all the time is Chrome (while the others are basically left alone - unless we’re talking about mesa, kde base software, etc.). But then again even if it were a “rogue” app I wouldn’t be able to just uninstall it. I might try installing it from the rpm (migrating the user profile) to see if it helps.
(I’ve modified your post to use preformatted text formatting to make the fdisk output more readable)
Looks like the full system is set up on a single partition. (EFI is for boot, and swap is separate, but home directories and root are all in sda2).
What is the output of sudo snapper list-configs? (Probably just root, but worth checking)
Also, it would be useful to see the output from snapper list - that includes space usage info for each snapshot, and that could be useful to see. Please use preformatted text (the </> button in the editor toolbar - or you can put “```” on the line before and the line after (without the double quotes), and that will do the formatting as well).
Yeah, number 72 isn’t too bad overall, if things are running well, you could delete 72/73, but that’s probably not necessary.
Something else you might try us running sudo zypper cc - I just upgraded an old laptop yesterday from 15.2 to 15.6, and during the upgrade, it ran out of space. I noticed that the zypper cache had a bunch of stuff from disabled repos, and that actually freed up a significant amount of space during the upgrade.
Something else that will help identify where the space has gone is to run:
sudo du -h --max=1 -x / | sort -h
Then drill down one level at a time on the directories that look the largest. Don’t just start deleting stuff (obviously), but that can help isolate where the space is going and be useful as a diagnostic to figure out what’s eating the space up.
