Bug#842299: autopkgtest-virt-qemu: attaching base image makes btrfs very confused

[Martin Pitt]

Hello Christian,

Christian Seiler [2016-10-30 20:04 +0100]:
> Well, one could do the following before attaching the base image
> (pseudo-code, untested):
> 
> if [ -e /lib/udev/rules.d/64-btrfs.rules ] ; then
>   echo 'KERNEL=="vd*", ENV{ID_SERIAL}=="BASEIMAGE", goto="btrfs_skip_baseimage"' > /etc/udev/rules.d/64-btrfs.rules
>   cat /lib/udev/rules.d/64-btrfs.rules >> /etc/udev/rules.d/64-btrfs.rules
>   echo 'LABEL="btrfs_skip_baseimage"' >> /etc/udev/rules.d/64-btrfs.rules
> fi
> 
> That would hopefully solve the problem for btrfs at least.

That's actually a nice idea. I wasn't aware that it's 64-btrfs.rules
which does that, as that only tells systemd to not mark the generated
.device unit as ready. I had assumed that "mount" does not care
about that all. Or maybe Simon actually means that the initrd and/or
systemd get confused about the two identical UUIDs during mounting?

But if that is indeed the culprit, then I think this can be both
simplified and generalized (not limited to btrfs) to just

  KERNEL=="vd*", ENV{ID_SERIAL}=="BASEIMAGE", ENV{SYSTEMD_READY}="0"

in /run/udev/rules.d/99-autopkgtest.rules. (Please not in /etc). We
generally just want this as a vehice to pass a file, we never want to
actually treat it as a live device.

> I'd also be open to investigating whether we could export the image
> via a custom 9p filesystem handler (that will just be a single
> directory with a single file in it). As Debian/Ubuntu kernels support
> 9p out of the box, this should work

Yes, it does -- autopkgtest already uses 9p to set up a shared
directory between the host and guest for passing in packages and
passing out logs/results. So we could in principle also just pass the
outer base image through that.

The reason why I don't like this is that the test then has to start to
understand QEMU image formats. It is much simpler/easier to let QEMU
do that interpretation and pass the image as a block device.

>  - I test the above hack with the udev rules to work around the
>    immediate problem so that Simon can use btrfs-based adt images.
>    A new version of autopkgtest is uploaded with that change.

I'm fine with uploading the generalized udev rule from above -- Simon,
could you test whether that works? (Sorry, travelling/at a
conference/not the bandwidth and time to build/test this myself).

>  - This bug is kept open until I can come up with an implementation
>    that doesn't use QEMU disk drives anymore but a custom 9p fs
>    handler. That way, we will never run into the same kind of
>    problem again in the future and bypass all udev/kernel etc.
>    logic. Performance would likely suffer a tiny bit, but not too
>    badly I hope.

Well, 9p performance is not great -- it outright sucks for lots of
small files and is okay-ish for few large ones -- but that could also
be access patterns instead of file sizes; on a base image you are
going to have lots of little reads and some writes, i. e. I'm afraid
it could well be in the "sucks" side of that scale..

So if we could find a way to neutralize this at the udev level, like
unsetting ID_FS_UUID and the like (if disabling it in systemd isn't
enough), I'd still prefer that.

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)