[frameworks-solid] [Bug 427092] btrfs multiple device handling

[Chris Murphy]

https://bugs.kde.org/show_bug.cgi?id=427092

--- Comment #22 from Chris Murphy <bugzilla at colorremedies.com> ---
> It seems we should try to have one entry by (subvol, uuid) pairs.

Maybe the immediate issue is to present a "Btrfs filesystem" as one icon,
rather than its true multiple device nature. Because there's more than one, it
invites the user to click each one, and if nothing happens to try it multiple
times.

The icon name might be "fs label" before mounting and "fs label:subvolume name"
once mounted. I probably wouldn't recommend subicons for subvolumes because
there could be many.

> But AFAICT udisk does not expose subvolume directly, we will need to parse
> the org.freedesktop.UDisks2.Block.Configuration or fstab field to find the
> subvolumes.

I think most users will use the "nested" layout for subvolumes and snapshots,
and therefore will behave like directories. But long term there may be hybrid
usage. There can be 2^64 subvolumes, each has its own pool of inodes. It might
be useful to develop a variant of the "Discoverable Partition Spec" for btrfs
subvolumes, whether by name or xattr, to allow services to take ownership of
their own namespace and enable filtering, and even self-describing assembly.


> For single subvolume case, your case; we need to depud things based on UUID.
> For some reason when mounted only /dev/vdb1
> /org/freedesktop/UDisks2/drives/VirtIO_Disk_1 got mounted.
> And since it shares its UUID with /dev/vdc1 which is not mounted, we should
> keep only /dev/vdb1.

I guess both are mounted, and that this is a limitation of the kernel in
listing more than one /dev/ node per file system.

> Now we'd need a way to figure out which block_device will be mounted when we
> mount a btrfs block_device.
> I.e is there a way to know/deduce before mounting /dev/vdb1 will be mounted
> instead of /dev/vdc1

Not sure, so I've asked on the upstream list here:

https://lore.kernel.org/linux-btrfs/CAJCQCtQiaAvNGKUiz28jBiw67rSJWp+Ei2uGet2F=xyaziu0nQ@mail.gmail.com/T/#u


> I don't know how to handle the multiple mountpoints for the same block :
>     MountPoints:        /run/media/chris/b5c151d7-46e9-413b-8061-54d52f655b67

I'd say back to the top, you'd want to avoid this. The user should see one
virtual device. That's what the kernel does for all the other cases, like with
mdadm or lvm, there's a single virtual block device with a file system on it,
and all the other devices in the layering aren't shown. Whereas with Btrfs the
real device and virtual device are one in the same thing, and leads to the
other member devices still being treated visibly.


> Should we expose only one ? Are they equivalent ?

I think this might be a udisksd bug, honestly. I mean, the DE is arguably
improperly asking for it to be mounted again, but udisksd isn't itself smart
enough yet to figure out this request should be ignored because it's not a
unique request for an additional resource (subvolume or snapshot) on the same
file system.

Probably udisks needs to return an error for this, to the effect of "i've done
that already".

-- 
You are receiving this mail because:
You are on the CC list for the bug.