I would say blkdiscard has little or nothing to do with it.
Because Wyng Backup also does snapshot management, I was faced with snapshot deletion causing long delays during the backup process. Or, at least they are long compared to the nearly instant decision Wyng makes when there are no changes in a volume to backup… it can’t decide without the snapshot, but deleting the comparison snap might take >10 seconds.
I determined that the deletion process was not critical to data integrity (its just cleanup) so I just spawned ‘lvremove’ background processes using ‘ionice’ without checking them. Wyng works much faster that way, although the rename (also slow) part of snapshot rotation can’t use a similar workaround.
OTOH, backups run faster on Btrfs even with that LVM-specific optimization, because deleting and renaming image files is so much faster than with thin LVs.
As for Qubes VM start/stop, perhaps there are snapshot rotation steps that can be left in the background and considered non-critical. For example, if VM startup always checks for the situation where a volume has been left in its active unsettled state (which it already does), and that unsettled volume name has the newest timestamp, then you can recover that situation easily with zero risk. So there could be a benefit to treating VM shutdown rotations as an unimportant background process (also using ‘ionice’).
Added my R4.2 results to the top. Times have returned back down to R4.0 levels.
Also, from here on assume that people reporting their times are using the latest available version of Debian for their release unless otherwise stated.
E.g. If someone posts for R4.1, then it’s assumed they’re using Debian 11. If for R4.2; Debian 12 until a template for Debian 13 is released.
Update my results for Qubes R4.2.0 with debian 12.
Fastest boot time was 3.390
10 run average was 3.496
R4.2 final release really has astonishing impact on individual qube boot time. Qmemman memory hotplug support since core-admin v4.2.18 (core-admin v4.2.18 (r4.2) · Issue #4121 · QubesOS/updates-status · GitHub) indeed boosted boot speed significantly, for qubes that have memory balancing on.
If we gotta figure out what makes debian-12 slower than debian-11, we may gain even further improvements.
I suggest grouping the big table in the original post by Qubes version, like three separate tables, for Qubes R4.0, R4.1, R4.2, respectively.
I’m still around 17s, but that’s better than 4.1. ^^
Also I noticed that my CPU load is less in 4.2 than in 4.1 - apparently qubesd or Xen are performing way better.
Not sure why you guys seem to get so much better results. Probably much better hardware (T530 here)…
I have no idea why it has been added or how it’s used, if used at all. It adds support for different executable formats, is it safe to disable/remove it?
I just masked the service in the tamplate I used to test, I believe you can just disable/mask it in the template and unmask/enable it from rc.local in the appvm.
If it isn’t needed, it should probably just be removed from the minimal template, and the user can manually install it if needed.
Is there a Linux guru who can help out? Lowering boot times with a quick tip will help a lot of people but I need more info lest this causes major issues.
I looked into it a bit more, I think systemd-binfmt is enabled as a side effect of upgrading systemd from v247 to v252, it adds After=local-fs.target to the default service file.
It didn’t need to autostart in D11, my gut feeling is that it also isn’t needed in D12, but I could be wrong.
I think the safe way to disable it, would be to copy the service file from /lib/systemd/system to /etc/systemd/system and remove the after line, it should allow the service to start if needed.