After running that I get 1572484 extents found. About 1/4 of what was there, but still a lot more than yours. manpages describes the time limit in a way that makes me think running it again could continue to improve it, so will try that.
EDIT: ran it second time, it ran much shorter time and reduced to 18167 extents found
Thanks all, this has been solved. In summary this was a qube hosting the monero blockchain, which is apparently prone to high fragmentation, so the solution was to defragment that qube.
I tracked it down starting with @flavio’s suggestion to use systemd-analyze blame, which blamed qubesd.
Then used @disp6252’s suggestion of journalctl -u qubesd.service to see more details that it was when moving around *.img files related to the qube “crypto” that the delays occurred.
@renehoj’s suggestion to not autostart that one qube actually fixed my long system boot time.
But the real solution was to defrag the qube. And since I’m using the filesystem XFS, @rustybird’s suggestion solved the problem:
sudo xfs_fsr /var/lib/qubes/appvms/crypto/private.img
I ran this on one other qube that seemed highly fragmented, and can now boot in under 3 minutes.
Thanks to all!
I’m glad you managed to resolve the issue! And it’s a good learning experience too!
Would this strategy with cp work for btrfs as well? Thanks!
It probably would, but instead of the final cp and rename steps I use btrfs filesystem defragment -f private.img (like xfs_fsr private.img for XFS).