Hi,
I've been having some issues in the past few weeks with a Fedora 25
AppVM (template updated from f24), sometimes the
qubes-mount-dirs.service unit takes ~5 minutes to complete and I'm stuck
waiting for it to finish.

The private.img of this AppVM is ~48GiB, but I have another 20GiB AppVm
that is working just fine.

Since I had some spare time, I've been looking at what is this unit
doing and... I'm quite puzzled.

Please note that I'm not a /bin/sh master, so I may have mis-interpreted
what happens here.

The unit file calls /usr/lib/qubes/init/mount-dirs.sh, which in turn
calls /usr/lib/qubes/init/setup-rwdev.sh.

And in this file, I may be mistaken here, but what I see is:
- the script checks if /dev/xvdb exists
- if it does, it gets the size into $private_size_512
- it then asks dd to produce that many 512-byte-sized blocks, and asks
diff to compare them to /dev/xvdb
- if they match, a filesystem is created

What I don't understand is... is this thing really comparing ~50GiB of
disk on every boot with a stream of 50 billion zeros just to see if a
filesystem exists? It's weird, because if this was the case I would have
to wait a long time on every boot, while this does not happen; on 1 in 3
boots, the VM starts up in ~20 seconds instead of the usual 5 minutes.

Checking in journalctl, I see that this check seems to last less than a
second when a boot succeeds. I'll add some more log lines in the
template and will try to catch the log for a long boot.

Other questions arise. Is it really necessary for the AppVM to try to
perform those steps (one being the zero-check, the other being the
resize2fs that immediately follows in the same script) on every boot?
why not something like /usr/sbin/blkid or /usr/bin/file, i.e. why the
specific all-zero check? And why not place some dot-file in the root of
the filesystem, like /.resize to signal a resize2fs to be done, instead
of having it run on every boot?

Thank you for your time,

-- 
Alex

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7e052233-f24b-4fc6-fd9c-e51211523189%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to