Boot time of 25 minutes due to fragmentation of monero blockchain [solved]

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).

1 Like