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

[Christian Seiler]

On 10/30/2016 09:01 PM, Martin Pitt wrote:
> 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.

Well, it's not actually SYSTEMD_READY, the "btrfs ready" builtin is
actually the culprit. (SYSTEMD_READY is still set for the baseimage,
the link_priority makes sure that single-device filesystems such as
ext4 don't care about it.)

If you look at src/udev/udev-builtin-btrfs.c in systemd's source
tree, you'll see that it does:

/* argv = { "btrfs", "ready", "/dev/...", NULL }; */
fd = open("/dev/btrfs-control", O_RDWR|O_CLOEXEC);
strscpy(args.name, sizeof(args.name), argv[2]);
err = ioctl(fd, BTRFS_IOC_DEVICES_READY, &args);

So one needs to make sure the btrfs ready builtin is never executed
for the corresponding devices. Which is why I did the LABEL/goto
logic in my example.

Luckily, /run also overrides /lib, so doing that with /run instead
of /etc is also feasible. (Assuming no one has customized the image
and overridden 64-btrfs.rules in /etc themselves. But if people
really want to customize their ADT images to that extent, they
should be able to investigate these problems and exclude the base
image in their custom rules themselves.)

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

Ok, good to know. I'll do some tests here and try to figure out how
to do that best with udev rules.

Regards,
Christian