R4-rc2 consuming all my disk space (250MB)

[Chris Laprise]

I currently have 4GB remaining on my drive according to the 'lvs' based
script from issue #3240.

However, I know I don't have nearly that much in templates and data;
there was a lot more free space on Qubes 3.2. Also, adding up the DISK
column from qvm-ls shows I should have over 100GB free.

So I'm wondering if this is a real problem with R4 and what can be done
about it.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Yuraeitha]

I believe this in-depth thread discussion on github may be in particular useful for your disk issues, as it pretty much appears to be a discussion on your exact issue.
https://github.com/QubesOS/qubes-issues/issues/3240

I don't think it was clarified to only happen on 'LVM Thin Provisioning', or LVM in general, but it seems like 'LVM Thin Provisioning' might be the culprit here?

So the solution appears to be a missing design in Qubes 4, which means either
1) Use a series of commands to detect the missing pool spaces (question is still how to approach this method though).
2) Possibly (big maybe), re-insteall QUbes with LVM instead of LVM Thin Provisioning?
3) Wait for a possible update in the future, i.e. by adding disk space uses to the 'qvm-volume list' output, or similar solutions.

From how I read it, it appears like the idea suggested late in the github thread of using qvm-volume (for example 'qvm-volume list --all' or another command?) to show the available total pool space and the total used pool space, for each storage pool, has been adopted as a major (UX user experience) bug in Qubes to-do in the Qubes 4 release (i.e. not waiting for Qubes 4.1. to fix this).

Albeit a brief read, I found the 'man qvm-volume' manual an intriguing read in combination to that github thread.

It also looks like Marek is working on implementing this approach into the qubes tools. If you scroll all down and follow the commit and reference trails. This looks really interesting.

This seems to have been implemented into the "core-admin v4.0.12 (r4.0)"
found here, https://github.com/QubesOS/updates-status/issues/313

This line specifically "QubesOS/qubes-core-admin@439d9b8 storage/lvm: fix importing different-sized volume from another pool" but notice the other volume change lines too.

If I'm not mistaken, the core-admin has not been released as of yet? So we have to wait for it to be released? At least I can't find it in my dom0 rpm search.

[Yuraeitha]

On Sunday, November 26, 2017 at 10:05:46 PM UTC, Chris Laprise wrote:

nvm, I found it.

Running 'rpm -aq | grep core-admin' in dom0, prints out the current qubes-core-admin-client version. Mine is 4.0.11-01. I'm fully updated to the testing repository. So since this was implemented in 4.0.12, we probably have to wait for that.

[Yuraeitha]

On Sunday, November 26, 2017 at 10:05:46 PM UTC, Chris Laprise wrote:

What is puzzling however is that looking down in the status links in the last link above, it shows that the core-admin v4.0.12 (r4.0) was already build and uploaded to the testing repositories.

I ran
qubes-dom0-update --action='clean all'
and
qubes-dom-update --enablerepo=qubes-dom0-update-testing

I still don't see the 4.0.12 version, that potentially proves this fix. What gives?

[Chris Laprise]

Thanks, but I found the underlying problem...

The dom0 root filesystem keeps allocating space because discard/TRIM
isn't enabled by default. The output from lvs showed that root was 50%
allocated, and since root is sized by the installer to be the same size
as the disk, that means 100+GB was allocated (root fs contents were only
4.5GB however).

An 'fstrim /' took care of the immediate problem and then I added
'discard' option to /etc/fstab. I think this should be the default for
new installs.

[Yuraeitha]

ah, good that it was resolved though.

I do remember a talk somewhere, think it was on github, about trimming being enabled automatically on Qubes 4, however, I think it was for LVM Thin Provisioning only, and not the regular LVM. At least for the current Qubes 4 RC2. I didn't pay much attention to this at the time, but I briefly remember.

I imagine it makes sense too, if picking one file system format over the other, that it might make a difference in how it writes the information in the fstab file. At least they are related to some extent. So one of either LVM or LVM Thin Provisioning, is not doing this correctly atm it seems.

Also.. loosing almost the entire drive space due to lack of trimming.... yikes...