On Thu, Jul 7, 2016 at 12:23 PM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote:
> > Here's how I would picture the ideal situation: > * A device is processed by udev. It detects that it's part of a BTRFS > array, updates blkid and whatever else in userspace with this info, and then > stops without telling the kernel. > * The kernel tracks devices until the filesystem they are part of is > unmounted, or a mount of that FS fails. > * When the user goes to mount the a BTRFS filesystem, they use a mount > helper. > 1. This helper queries udev/blkid/whatever to see which devices are part > of an array. > 2. Once the helper determines which devices are potentially in the > requested FS, it checks the following things to ensure array integrity: > - Does each device report the same number of component devices for the > array? > - Does the reported number match the number of devices found? > - If a mount by UUID is requested, do all the labels match on each > device? > - If a mount by LABEL is requested, do all the UUID's match on each > device? > - If a mount by path is requested, do all the component devices reported > by that device have matching LABEL _and_ UUID? > - Is any of the devices found already in-use by another mount? > 4. If any of the above checks fails, and the user has not specified an > option to request a mount anyway, report the error and exit with non-zero > status _before_ even talking to the kernel. > 5. If only the second check fails (the check verifying the number of > devices found), and it fails because the number found is less than required > for a non-degraded mount, ignore that check if and only if the user > specified -o degraded. > 6. If any of the other checks fail, ignore them if and only if the user > asks to ignore that specific check. > 7. Otherwise, notify the kernel about the devices and call mount(2). > * The mount helper parses it's own set of special options similar to the > bg/fg/retry options used by mount.nfs to allow for timeouts when mounting, > as well as asynchronous mounts in the background. > * btrfs device scan becomes a no-op > * btrfs device ready uses the above logic minus step 7 to determine if a > filesystem is probably ready. > > Such a situation would probably eliminate or at least reduce most of our > current issues with device discovery, and provide much better error > reporting and general flexibility. It might be useful to see where ZFS and LVM work and fail in this regard. And also plan for D-Bus support to get state notifications up to something like storaged or other such user space management tools. Early on in Fedora there were many difficulties between systemd and LVM, so avoiding whatever that was about would be nice. Also, tangentially related, Fedora is replacing udisks2 with storaged. Storaged already has a Btrfs plug-in so there should be better awareness there. I get all kinds of damn strange behaviors in GNOME with Btrfs multiple device volumes: volume names appearing twice in the UI, unmounting one causes umount errors with the other. https://fedoraproject.org/wiki/Changes/Replace_UDisks2_by_Storaged http://storaged.org/ -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
