I’m trying to get to the bottom of what’s using up all the disk space.
I’m showing 375gb out of 500gb used.
(There’s no way possible that 375gb is used.)
The Qubes Manager disk usage totals don’t come anywhere close to a 1/10 of that.
Is there a disk usage utility in Dom0 that will help get to the bottom of it?
I’ve been cloning/deleting allot of qubes to test things. I’m wondering if those qubes are still taking up memory, and how the best way to reclaim that memory, without reinstalling?
Another anomaly is the disk usage applet reports 21% used. Partion manager reports 81% used.
What does right clicking on the 'Qubes Disk Space Monitor` icon show (icon is in the desktop upper panel left end)?
The partition manager may be displaying the amount used by the partition on the physical volume. If the logical volume includes the partition, then the amount used within the logical volume is probably of more interest.
Okay… so I’ll be the first to ask it. Could this be related to all the work you have been doing to create “ghost layers” and “hidden OS partitions”? Is it possible that one was created, recognized as used disk space by Qubes and somehow even after deleting it, Qubes is still accounting for the space? Or something similar to that?
Well, I’ve been cloning, testing, deleting plenty of Qubes to test things. I still haven’t changed much with storage pools or changed partitions on the primary HD yet.
I can imagine that all those clone/deleted qubes are taking up disk space. And I can imagine its a simple command to reclaim it. I just don’t know what that command is.
I don’t think cloned and deleted VMs would cause this trouble. Creating partitions would. Possibly tinkering with storage pools? Not sure.
sudo fstrim -av && sudo shutdown -h now
Notably, fstrim discard commands, when sent through the PV disk drivers built into the Linux kernel, translates to: “dom0 LVM, I am not using this space any more in this LV, you may free it.”
Assuming default installation, always keep in mind that recovering space from deletions performed inside VMs stored in the primary storage thin pool may take two VM shutdowns, as the default behavior is to keep one backup snapshot of volumes.
For templates, while I do use the Qubes Updater specifically to capture special cases, I am still also manually invoking updates (old habits die hard) afterward. As part of that manual approach I force removal of any cached packages to recover space, e.g.:
# for fedora
sudo dnf upgrade && sudo dnf clean all && sudo fstrim -av && sudo shutdown -h now
# for debian/whonix
sudo apt-get update && sudo apt-get --with-new-pkgs upgrade --fix-missing && sudo apt-get clean && sudo fstrim -av && sudo shutdown -h now
I have some other scripts for removing logs, cleaning out firefox caches, etc. Mostly just to recover wasted storage space.
B
Thanks. I ran the commands in dom0 & the templates for the upgrades.
Not much changed in the disk usage picture.
Do you have the scripts that recover other storage space handy?
I apologize for making dummy assumption: is it possible that the term “used” is mixed with “occupied”? Is it possible that 375GB is used by Qubes OS, of which is ~50GB occupied with data, and the rest of ~325GB is still used by Qubes (reserved for it) but available for further occupying? Free space is the space out of Qubes OS (unallocated, not formatted section of HDD, thus “free”).
I apologize for trivial language.
A screenshot of KDE-partitionmanager would be helpful, probably)
What would be helpful would be to see the output of
sudo lvs
on your system, perhaps with the “vmname” part of the LV names replaced with other names if you have concerns about that.
Otherwise, very hard to tell what the issue is.