In LVM I was able to utilize SSD speed while keeping my big private disk vm on hdd, by making a dedicated thin pool in SSD, add this pool to qubes os and then cloning my template vm onto the new pool. In this way I can access the root.img of each vm from SSD
What are the counterpart in btrfs? In btrfs when I specify “DUP” profile, the one gets read is determined by pid parity (BTRFS raid-1: which device gets the reads? - Stack Overflow). I am not sure whether the storage driver in qubes os always picking the ssd or hdd. (anyone knowing this or experimented on this)
If I chose “SINGLE” profile, I did not find any reliable way to move blocks of one img from hdd to ssd; not mentioning to make all new blocks onto the ssd.
About caching solutions, bcachefs does not exist until kernel 6.7. And I don’t know whether it is stable. I also see ZFS and LVM itself has such functionality.
Anyone who has such experience? I am seeking for a btrfs solution since I found that btrfs compression functionality and dedup are very useful for saving spaces.
I wouldn’t recommend mixing a ssd and a hard drive in a same pool. They have a latency with a different magnitude of order, and usually things align to the slowest member of a pool.
There are fuse filesystem that allow caching like bcachefs or zfs does, but I’m sure they are super reliable and that they would integrate well on Qubes OS.
You could similarly create an independent Btrfs filesystem on the SSD (or rather, on a new LUKS device on the SSD), set it up to be automounted, and add another file-reflink Qubes OS storage pool somewhere on the mountpoint.
+1
This is just a guess but maybe Btrfs would decide based on whatever happens to be the PID of (one of) the kernel thread(s) servicing the xen-blkback device corresponding to the VM volume?