Multi-device btrfs may timeout for "missing" device due to race in device link creation.

[arvidjaar]

btrfs multi-device processing relies on announcing only the last device that resulted in btrfs being assembled and ready for mounting. This means that only UUID or LABEL can be used to mount btrfs on assumption that these links will point to the last device. But even these links are not deterministic - event for device that caused btrfs to become complete may be processed faster than event for other btrfs devices, so UUID or LABEL link may point to "non-existent" devices (those with SYSTEMD_READY=0). As we never reset SYSTEMD_READY, it means required device is never present and mounting fails.

This is cloned from issue 5781, more details are present in #5781 (comment)

[mbiebl]

@arvidjaar We have this old downstream bug report which looks related
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740208

[arvidjaar]

And to round it off, I now have situation when link is wrong but does not match systemd state:

localhost:~ # ll /dev/disk/by-label/
total 0
lrwxrwxrwx 1 root root 10 May  1 20:32 Storage -> ../../dm-0
localhost:~ # systemctl --no-pager status /dev/disk/by-label/Storage
● dev-disk-by\x2dlabel-Storage.device - /dev/disk/by-label/Storage
   Follow: unit currently follows state of sys-devices-virtual-block-dm\x2d1.device
   Loaded: loaded
   Active: active (plugged) since Mon 2017-05-01 20:31:55 MSK; 6min ago
   Device: /sys/devices/virtual/block/dm-1

May 01 20:31:55 localhost systemd[1]: Found device /dev/disk/by-label/Storage.
localhost:~ # 

I have no idea how is it possible.

[poettering]

Uh, afaics this is a duplicate of #5781. Let's keep discussions at one place, please.