Also I switched to BTRFS about two weeks ago. I am seeing the same improvements @Sven reports.
Also it seems I was corrupting my LVM system doing hard shut downs when a 600gb VM I constantly have open would prevent the system from shutting down. Now because the system actually shut downs I suspect I won’t run into an unstable system so easily.
However this is one constant error I’m seeing during shut down in the terminal and that’s a [FAILED] Stopped (with error) /dev/dm-0, maybe @rustybird knows what is causing this?
I hope this doesn’t bring back my stability issues or a failed boot directory which happened often before.
Hmm one thing that might help is doing an extra step of shutting down all your VMs ($ qvm-shutdown --all --wait, then check e.g. in the domains widget that they’re really all gone, maybe even wait a few more seconds) before you shut down the system as a whole.
Normally that should be automatic, but I suspect there’s a bug in some layer of the shutdown procedure.
This works to prevent the error. So I’ll just use this when shutting down until I gain the experience required to troubleshoot more and submit a correctly formatted bug report. For the interim, thank you!
I just installed 4.1 and intended to configure it with BTFS with my laptop/SSD but kept going round in circles.
When you accept the default partitioning you get LVM, but if I selected custom option and BTRFS it only gave an error saying it could not validate the disk configuration, and nowhere does it say why. I’m guessing that I needed to also set up the partitioning on my own but there is nothing that even gives a hint what sizes for what partition or even how many partitions I needed. I was just stuck in a loop until I gave up and went with the LVM default. I’ll have to redo it obviously but realized I needed to do some research, but before trying again I thought I would ask a question: Why do we not have an automatic option where you can just select between LVM and BTRFS as an option? Either that or the custom section should give a hint on what it needs to be successful.
I tried again and the trick is apparently is to manually delete the partitions before clicking the “Click here to create them automatically”. After doing that I was able to continue but got an exception from anaconda during the actual partitioning.
"Error: use the -f option to force overwrite of /dev/mapper/luks-{big hex number} "
Since I don’t have a running system yet I could not copy the entire stack trace off the system. The attached photo is the top of the trace. I’ll go back and try again to see if I can get past this error somehow.
My next attempt was successful installing 4.1. with btrfs. I still have no idea what went wrong with my previous attempts other than possibly user error. In any case, this time it worked. I can’t wait to explore the new system.
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.
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”
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.
@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:
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?