Chris Murphy

Is it possible to post the kernel messages that appear at the time of this failed mount? There should be: > kernel: BTRFS: device fsid 15dccc1e-7c38-4456-a2fe-83d0d5051adb devid 1 transid 6...

* Both `rootflags=subvol` and `btrfs subvolume set-default` methods for specifying the system root should be supported. Both support subvolid. * Compression should support both `compress` and `compress-force` including mixed use...

Yes, it's confusing for me as well. Here are some breadcrumbs. `btrfs device usage` wants a mounted file system, and the mount is failing in this case I'm guessing because...

What additional information is needed? Is there something upstream needs to provide or explain?

`btrfs device ready` acts on a block device, not on a mount point. systemd-udev already has a wrapper for this in src/udev/udev-builtin-btrfs.c which is then used by rules/64-btrfs.rules. If a...

>Yes, but it doesn't seem to work as we expect/need. The user space command doesn't seem to work as anyone expects, so I'm kinda beating up on upstream about what's...

OK that upstream thread has been updated, and now I understand. Our tests are flawed due to misunderstanding how the devices_ready ioctl works. Once the kernel sees all devices, `ready`...

If mounting normally succeeds, by definition all devices are present. There's no harm in trying, but if they aren't all present, you get a generic mount failure message and therefore...

> Yes, multiple devices won't be easy. I'm open to suggestions, I've never really tried to resize a raid/complex btrfs volume. One approach might be listing common use cases, and...

>Unfortunately this is not the case with xfs_admin I mentioned it to @djwong (XFS maintainer) and he said it's an oversight that it was missed, xfs_io did get this enhancement....