I moved to R4.1 with Btrfs and it’s been a while, I’m experiencing the same performance improvements. This is especially noticeable when the VM uses swaps.
My SSD is a 860 EVO (TLC) and it’s fine, but other SSDs may have performance degradation.
1 Like
That issue ^^^ appears to be independent of any particular filesystem or storage driver, its current title is “4.1rc2 VM startup performance degrades linearly with the number of running VMs”
2 Likes
My post is too old to edit but I just noticed that this only applies to R4.0. In R4.1 it was fixed and the upfront delay should be gone, no matter which storage driver is being used.
1 Like
A post was split to a new topic: Hard Disk I/O Makes Qubes Completely Unusable After Upgrade to dom0 kernel 5.10.112-1
@marmarek Sorry if this is wrong place for asking, but I wanted to have insights on where the ecosystem is moving.
- TLVM adds lots of overhead, complexity and performance penalties
- BRTFS is offered as second installation candidate under QubesOS installer, where XFS is not offered
- TLVM is still default installation method
- 4k templates are coming along, proving BRTFS to be resilent here, and where TLVM would probably benefit and loose some drawback performance points when compared to BRTFS.
The Reason I ask is that other OSes switched to BRTFS and I’m wondering if Heads should also take steps into having brtfsprogs built and included. wyng-backups now supports xfs/brtfs as well. But as you know, Heads cannot pack everything for all use cases so question here is:
Is QubeSOS default partitioning scheme expected to change to BRTFS by default on Q4.2 release or is TLVM still expected to stay the default instlalation method?
cross-linking to issue showing newer OS installers and Heads documentation and filesystem support might need to be reconsidered:
3 Likes
Answer was: not for 4.2. And no. Templates 4k are not coming.
Nice discussion though: Switch default pool from LVM to BTRFS-Reflink · Issue #6476 · QubesOS/qubes-issues · GitHub
Would be a good time to distill Switch default pool from LVM to BTRFS-Reflink · Issue #6476 · QubesOS/qubes-issues · GitHub content prior of continuing investing energy under Bees and brtfs deduplication
Meaning: why go BRTFS with bees (offline dedup) if OpenZFS can do what BRTFS but better (compression, encryption) with online dedup (and therefore no need of a background running daemon like bees that dedup AFTER the fact instead of as write happen on FS…). OpenZFS is sooo sexy to say the least. BRTFS performance tests from QubesOS team (offline discussions) to switch to BRTFS are no go…
This would need OpenZFS deployment under Qubes ISO though, which I guess would need its own efforts and not waste efforts on going sideways. Agreed that Ubuntu deploys it (DKMS), while Fedora doesn’t take a stance there and where Oracle didn’t change licence even today. Will need participation in other threads; not this one.
ZFS pool as of today exists. But instructions for install are manual even if really good. Would need to test and convince @marmarek to have OpenZFS inclusion even if Fedora doesn’t take a stance 
@Rudd-O : Can you point to the conclusions (read your articles) that could make QubesOS budge on considering integrating OpenZFS into the QOS installer?
3 Likes
If switching to another file system now then bcachefs would be the better option.
ZFS has been an industry standard for 15 years now while bcachefs just got merged within the linux kernel.
Problem here is licensing and depending on dkms after new kernel deployment. Or consider this the other way around and check how gentoo/Ubuntu decided to go OpenZFS way while Fedora didn’t. I highly doubt QubesOS will differenciate their ways from Fedora, and Fedora is not talking about it while Oracle doesn’t budge on licensing issues.
Not sure how OpenZFS would be included, even less with understood goal of going eventually UKI way (where initrd+kernel+boot options would be delivered under a signed unified kernel).
How to get this debate forward? OpenZFS seems to be the way.
Why bcachefs, @quantum?
Can I import a Qubes Backup from an LVM install into a new install with BTRFS ?
Is Qubes Backup even available on installs with BTRFS?
I really want snapshot capability in some qubes.
Yes, it should work.
Yes.
2 Likes
And vice versa too.
Individual qubes (restored or newly created) use ext4 as their internal filesystem, so you wouldn’t get snapshotting/reflinking inside of them by installing Qubes OS with the Btrfs installation layout.
Nice.
I read that Btrfs over Btrfs is really stupid.
I guess I will stay with LVM but I would really like to replace ext with btrfs in certain AppVMs how do I do that?
I guess just use btrfs-convert (on home partition) in certain app-vms and then edit the fstab (and make it persistant) . Will I run into any Issues with this ?
And just in general is this a bad idea ?
Just noticed that the fstab doesn’t have a filesystem type for the home mount. What should I do here ?
That’s tricky while the AppVM is running. Don’t do it in dom0 either. Try How to mount LVM images | Qubes OS (replacing the mounting/unmounting in steps 4 and 5 with btrfs-convert).
No need, it already has the filesystem type set to auto.
No, but
Make sure you have backups though.
1 Like
Thanks converted successfully. I also tested resizing but don’t know how ( In the VM it says that the added storage is filled). Is this something I will have to do in dom0 or inside them VM?
I guess that I have to mount the private-image again in another Qube and do some magic there?
No you would first resize the ‘private’ volume normally (using the qube’s Settings GUI or the qvm-volume resize CLI), and then resize the filesystem on the volume by running sudo btrfs filesystem resize max /rw inside the qube.
1 Like
Speaking of this, what I have been doing is converting (from ext4 to btrfs) and resizing the private.img files directly in dom0. I was a little bit hesitant to do it in r4.2 (because of older version of btrfs-tools in Fedora 37). But doing this in Fedora 41 sounds very safe. I wonder if someday, this feature would be better added to qvm-volume itself rather than letting VM do it on 1st boot (at least for private volume). This way we could get rid of such issues:
1 Like