unmount at the end of take_filesystem_ownership often fails because device is busy

[AdamWill]

In Fedora, we have recently added an openQA test intended to test the GNOME Disks application. It's backed by a 1.1GB disk image file, /root/disk.img, which we loopback mount with losetup -P -f --show /root/disk.img to provide a handy "disk" for testing.

One of the tests involves formatting the disk, creating three new partitions, then mounting them. However, this test is quite often failing because when the test comes to mount one of the new partitions, it is already mounted at /run/udisks2/temp-mount-(RANDOMSTRING). In the system journal, we see these messages:

May 18 10:55:57 fedora kernel: EXT4-fs (loop0p1): mounted filesystem b8cb6707-b6f3-4c09-8b90-c09b541bfee6 r/w with ordered data mode. Quota mode: none.
May 18 10:55:57 fedora kernel: EXT4-fs (loop0p1): unmounting filesystem b8cb6707-b6f3-4c09-8b90-c09b541bfee6.
May 18 10:56:24 fedora kernel: EXT4-fs (loop0p2): mounted filesystem 554be809-3a6a-4243-993e-e839f87fc3d3 r/w with ordered data mode. Quota mode: none.
May 18 10:56:24 fedora udisksd[624]: Error unmounting temporary mountpoint /run/udisks2/temp-mount-I80041: target is busy
May 18 10:56:24 fedora udisksd[624]: Error removing temporary mountpoint directory /run/udisks2/temp-mount-I80041.

looking at the udisks2 source, it looks to me like we're in take_filesystem_ownership in src/udiskslinuxfilesystemhelpers.c, here. It seems to me like, maybe, that is not actually waiting for the recursive_chown operation to be fully committed to the filesystem before attempting to unmount it, or something?

I can tweak the test to try and workaround this by manually unmounting each partition after creating it if it still seems to be mounted, but it seems a bit ugly.

[AdamWill]

So I tweaked the test to manually unmount the partitions if this happens. However, we're still seeing it fail sometimes during another part of the test which tests resizing partitions, and I think it's actually for the same reason. The test gets stuck at this screen for much longer than expected, and times out:

looking at the logs, right around the time it gets stuck, are the same kinds of message, right after a message that looks related to the resize operation:

May 20 03:33:03 fedora udisksd[662]: Requested start of the logical partition overlaps with extended partition metadata. Start of the partition moved to 1.
May 20 03:33:03 fedora kernel: EXT4-fs (loop0p1): mounted filesystem a5978015-5385-4ae4-b571-c578621167c6 r/w with ordered data mode. Quota mode: none.
May 20 03:33:03 fedora kernel: EXT4-fs (loop0p1): unmounting filesystem a5978015-5385-4ae4-b571-c578621167c6.
May 20 03:33:31 fedora kernel: EXT4-fs (loop0p2): mounted filesystem cf64b7e6-b64d-4d14-9b46-d161d19121e4 r/w with ordered data mode. Quota mode: none.
May 20 03:33:31 fedora udisksd[662]: Error unmounting temporary mountpoint /run/udisks2/temp-mount-7RQI51: target is busy
May 20 03:33:31 fedora udisksd[662]: Error removing temporary mountpoint directory /run/udisks2/temp-mount-7RQI51.

so I think we hit this same "failed unmount of temporary mount" problem as part of the resize workflow, and it results in the UI getting stuck as it's waiting for the unmount to happen, or something along those lines.

[tbzatek]

I suppose this is gvfs automounting kicking in. Looking at take_filesystem_ownership() code there's much left to be improved. Beside multiple unmount tries we can also lock the device and avoid presenting it as ready/usable/automountable until any running operation is finished.

Mounting any filesystem for the sole purpose of resizing, getting filesystem size or taking ownership and unmounting it afterwards has always been source of problems since there's typically something else that registers a new mount and trying to sniff or index it (e.g. the tracker indexing service?).

I think we had an idea to make use of a private mount namespace for such temporary things but no work has actually been done on that part.

[tbzatek]

Needs storaged-project/libblockdev#894