Comment # 2 on bug 912170 from Andrei Borzenkov

Yes, I can reproduce it. Setup - two encrypted containers and btrfs on them as
raid0 for both data and metadata.

The bug is in patch
1060-udev-use-device-mapper-target-name-for-btrfs-device-ready.patch. When
btrfs builtin runs, /dev/mapper link is not yet created so builtin fails. This
results in SYSTEMD_READY being not set and systemd attempts immediately mount
multi-device filesystem without second device being available. 

1392  open("/dev/btrfs-control", O_RDWR|O_CLOEXEC) = 7
1392  ioctl(7, BTRFS_IOC_DEVICES_READY, 0x7ffff80a3520) = -1 ENOENT (No such
file or directory)

Cc'ing Jeff who was the author of patch. I am not sure what the statement 

--><--
If the device is a DM device, udev will have already cached the table name
from sysfs and we can use that to pass /dev/mapper/<name> to the builtin
so that the correct name is used.
--><--

is based on - as far as I can tell, udev is passing argument verbatim, without
doing any processing. Nor do I understand what problem was supposed to be fixed
here.

@Ryan - as a workaround, copy /usr/lib/udev/rules.d/64-btrfs.rules into
/etc/udev/rules.d/64-btrfs.rules and replace the following two lines

ENV{DM_NAME}=="", IMPORT{builtin}="btrfs ready $devnode"
ENV{DM_NAME}=="?*", IMPORT{builtin}="btrfs ready /dev/mapper/$env{DM_NAME}"

with single one

IMPORT{builtin}="btrfs ready $devnode"

If you will have *any* issues, please mention them here.