Any suggestions on mixing ssd and hdd in btrfs

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.

1 Like

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.


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?