Qubes VM Manager becomes unresponsive for a while when trying to backup (excessive disk IO)

[Jimmy Axenhus]

Hi!

Whenever I try to make a backup with the Qubes VM Manager (System ->
Backup VMs) it appears to be freezing and I have to wait several minutes
for it to start responding again. I've been able to make backups before,
but after not having done it for a while I decided to go ahead and do it
again. Before it was really fast and worked without any issues. The VM
Manager is not completely stuck though as I can see the CPU going up and
down using top.

Investigation of qubes-manager by inspecting the stack by modifying[1]
/usr/bin/qubes-manager and using iotop shows that the process is
spending most of it's time reading from the disk. qubes-manager seems to
spending most of it's time in
/usr/lib64/python2.7/site-packages/qubes/qubesutils.py, function
get_disk_usage(). The stack trace I got indicated that it was calling
os.walk(). The path it was scanning was one which I know is on a
secondary slow HDD and contains *plenty* of subdirectories and files.
Looks like this is causing the problem.

I use an SSD for Qubes, but got a secondary HDD attached to dom0. The
HDD is being mounted automatically on boot. When it worked fine I only
had the SSD.

If I wait long enough it will abort the backup attempt and become
responsive again, but that's because of some permission issues on the
contents of my HDD that I need to fix.

It would be much better if the Qubes VM Manager GUI didn't freeze and
instead provided some kind of feedback of what it is doing.


[1]:
http://stackoverflow.com/questions/132058/showing-the-stack-trace-from-a-running-python-application

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Jun 20, 2016 at 10:39:30PM +0200, Jimmy Axenhus wrote:
> Hi!
>
> Whenever I try to make a backup with the Qubes VM Manager (System -> Backup
> VMs) it appears to be freezing and I have to wait several minutes for it to
> start responding again. I've been able to make backups before, but after not
> having done it for a while I decided to go ahead and do it again. Before it
> was really fast and worked without any issues. The VM Manager is not
> completely stuck though as I can see the CPU going up and down using top.
>
> Investigation of qubes-manager by inspecting the stack by modifying[1]
> /usr/bin/qubes-manager and using iotop shows that the process is spending
> most of it's time reading from the disk. qubes-manager seems to spending
> most of it's time in /usr/lib64/python2.7/site-packages/qubes/qubesutils.py,
> function get_disk_usage(). The stack trace I got indicated that it was
> calling os.walk(). The path it was scanning was one which I know is on a
> secondary slow HDD and contains *plenty* of subdirectories and files. Looks
> like this is causing the problem.
>
> I use an SSD for Qubes, but got a secondary HDD attached to dom0. The HDD is
> being mounted automatically on boot. When it worked fine I only had the SSD.
>
> If I wait long enough it will abort the backup attempt and become responsive
> again, but that's because of some permission issues on the contents of my
> HDD that I need to fix.

It is probably mounted somewhere inside your dom0 home. When you select
to backup it (it is by default), manager needs to calculate its disk
usage. If you want to skip this, simply don't select "dom0" to backup.

> It would be much better if the Qubes VM Manager GUI didn't freeze and
> instead provided some kind of feedback of what it is doing.

Yes, space calculation (unlike performing backup itself) is running in
the GUI thread. That space calculation shouldn't normally take much
time...

> [1]: http://stackoverflow.com/questions/132058/showing-the-stack-trace-from-a-running-python-application
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXaFd/AAoJENuP0xzK19cs248IAJl3tDNgFJWwqMbQ4z5VRWrM
xX1FBKj9OIF5T1k+xpwRJKKDbFPLlLBE8Z+5yFb4X4zMLDbGL7ff6Lob2/+5BvJR
4sMd4YlTaerIwmt8iuHmAMCQJlGU0No/V0/Anq66gNFuMCpGrU0qFusViHEl5AOK
O/yRjkLVl+zYlTFZDQbopBnVkzN4uFERyzZmeEjMmP0NVEV5b/lpG4ri+S4gMG5X
6cYQt/Duh2XRhObBQxzZYX1r3ckYVl0RmcbzruzEEnuN2O5KdHdWVV4byno+9Nf7
kfwY1ae0s6AC7QbMQOZJc9ZsS1xt0zdTB72PuoUnMqh0UdV8mY69f+qHaTlh1JA=
=oxTJ
-----END PGP SIGNATURE-----

[Jimmy Axenhus]

I moved the HDD to /media/hdd and that solved it! The GUI is no longer
freezing or becoming unresponsive and its now as fast as it used to be.
Guess I shouldn't be mounting disks inside /home in the future.

Thank you for your help!