I always use this trick for my RAM qubes to avoid such situations:
Although it is RAM-based, I try to use its “disk” as little as possible because (as you have seen yourself) this consumes RAM from the pool (and from dom0).
Instead, I use a big tmpfs RAM drive and do everything in it - downloading, etc. That allows to use very little from the pool.
For example, I have a RAM qube that has 20GB tmpfs storage but uses only 200M from dom0 with params:
... -p maxmem=0 -p memory=20000 -s 200M
It is a Whonix qube inside which:
user@host:/tmp/download > df -h /tmp/
Filesystem Size Used Avail Use% Mounted on
tmpfs 19G 12K 19G 1% /tmp
So, the RAM is consumed from Xen, not from dom0.
Here is a handy /rw/config/rc.local for auto-sizing the tmpfs:
However, it would also be possible to adapt this thread’s script to create a throwaway Btrfs/XFS filesystem (maybe even on disk, encrypted with a random key) and then use the file-reflink driver for the temporary pool.
I am testing with XFS which seems the better choice. The only drawback so far seems the FS metadata that consumes some space.
A strange thing I found is that detached loop devices remain and pile up in qui-devices. No idea why and there is no man page for qui-devices. Do you know how to hide them from there?
The same one from the OP. It is not an anti-forensic tool. Just helps to keep the system clean from unused files related to non-existing qubes. It has also nothing to do with WiFi.
I will post a new version of RAM qubes when ready. Don’t hold your breath though.