Persistence in AppVM - should symlinked items cause persistence?

I’m noticing that an AppVM is huge - even though it shouldn’t be - there is almost nothing in /home, /usr/local, etc.

However, one thing I know: My setup has a few symlinks in /home/user/ that point to some huge items in the root.

But should this really cause the AppVM size to bloat? The symlinks themselves are very small, after all. (I’m looking at the size in the Qubes Manager after the AppVM has shut down)


I do recall a time where symlinks in /home/user pointing to larger items in root didn’t bloat my AppVM size - but at some point this started happening.

No ideas at all?

Try qvm-volume info VMNAME:private usage in dom0 to verify that it’s not just an artifact of Qube Manager’s disk space reporting.

If the AppVM is actually bloated, running sudo fstrim /rw inside it might help.

1 Like

This did the trick, thank you :slight_smile:

More details:

  • After running qvm-volume info VMNAME:private usage I was seeing the large number - actually a number 4GB larger than the Qubes Manager.
  • After starting VM, running sudo fstrim /rw inside, shutting down VM, and quitting/starting Qubes Manager, it now shows me the expected low number.
  • And so does qvm-volume info VMNAME:private usage except again it’s 4GB larger.

So the issues is fixed in that most of the bloat is gone, but what does this mean? Follow up questions:

  • Can you please elaborate a bit on what that commands did? What is “/rw”?
  • What’s the meaning of thoes extra 4GB (left out by the Qubes Manager)?
  • Does this mean my previous Qubes Backups were larger than they needed to be - or did the Qubes Backups automagically use the correct lower space?
  • Are these commands something one should run as a habit in Qubes OS, to make sure disk space is not being wasted?

It’s a directory in the private storage, just like /home, therefore it survives a qube restart.
You can read more on that in the following links:

It discarded/trimmed unused blocks on that filesystem.

1 Like

/rw is the mountpoint for the private volume’s filesystem containing the AppVM’s data. E.g. /home is bind mounted from /rw/home.

fstrim told the storage system in dom0 which parts the VM filesystem currently considers to be unused, so that they can be discarded.

Did you maybe divide the byte size by 1000^2? One MiB as shown in Qube Manager is 1024^2.


/rw is mounted with the discard mount option, so normally data is discarded automatically. But I think this could get out of sync in case of a crash (or maybe even a regular shutdown) right after deleting some files.

VMs also come with a systemd unit fstrim.timer that runs a VM-wide fstrim command. Ideally this should catch cases like yours where the VM’s and dom0’s view of unused data went out of sync, but it’s scheduled “weekly” and if it’s in a short-running VM I’m not sure if the timer will ever really trigger.

1 Like