Disk usage numbers in Qube Manager are deceptive

[ddevz]

How to file a helpful issue

Qubes OS release

4.1

Brief summary

After the Qubes storage widget tells a user they are low on disk space, one can try to free up space by deleting qubes from the Qube Manager. However, the disk space listed under "Disk Usage" is not always the amount that becomes free if you delete that qube. (particularly templates)

I suspect this is related to "cloning" a template making a copy-on write copy of the template instead of a full copy of the data (which is a good thing, but it makes it confusing for the user to try to understand how to free space)

There is also the confusing factor that certain deleted disk space only shows up as free in the Qube storage widget after a reboot.

[DemiMarie]

For the LVM storage driver, getting the actual amount of space used requires using the thin_ls command and somehow figuring out which thin volume corresponds to which logical volume. Not sure about reflink or file.

[ddevz]

From a UX perspective, a user probably needs to have both the current number and the "thin number" in Qube Manager. Presenting just the thin number to the user would probably cause confusion for many people when they first see it.

Also from a UX perspective, it'd be related to #5679 and #4398

[marmarek]

Generally, any kind of copy-on-write pool (which are both lvm thin and btrfs) made it rather hard to answer "how much space this thing uses". That's because part of the VM disk may be shared with something else. I mean, technically you can figure it out, but then presenting it to the user is tricky. Lets use an example:

1. Template1 has 10GB disk, fully utilized for simplicity
2. Template2 was created by by cloning Template1, and then 2GB was modified.

This means, 8GB out of those 10GB are shared between those templates. If you remove just Template2, you will free up just 2GB, but if you remove Template1 first, then removing Template2 will free up whole 10GB.
But then, presenting just "not shared" amount is not enough either, as it doesn't represent how much data you have there.

[andrewdavidwong]

Generally, any kind of copy-on-write pool (which are both lvm thin and btrfs) made it rather hard to answer "how much space this thing uses". That's because part of the VM disk may be shared with something else. I mean, technically you can figure it out, but then presenting it to the user is tricky. Lets use an example:

1. Template1 has 10GB disk, fully utilized for simplicity
2. Template2 was created by by cloning Template1, and then 2GB was modified.

This means, 8GB out of those 10GB are shared between those templates. If you remove just Template2, you will free up just 2GB, but if you remove Template1 first, then removing Template2 will free up whole 10GB. But then, presenting just "not shared" amount is not enough either, as it doesn't represent how much data you have there.

How do other OSes and tools handle this?

[ddevz]

How do other OSes and tools handle this?

one example is the zfs zfs list -t snapshot command which gives a "used" number and a "referenced" number. (referenced being the number as currently computed by Qubes Manager, and used being the "thin number")

[comods]

What about using "Physical Disk Usage" (Space freed if qube is deleted) and "Virtual Disk Usage" (Used space as seen from inside VM, i.e. no-ref-deep-clone size).