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

Méven Car bugzilla_noreply at kde.org
Fri Dec 18 08:29:33 GMT 2020


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

--- Comment #21 from Méven Car <meven29 at gmail.com> ---
It seems we should try to have one entry by (subvol, uuid) pairs.

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.
And then build the tree Block to VirtIO Disk to btrfs fs.

mount aka mtab could be leverage as well:
/dev/vdb1 on /run/media/chris/b5c151d7-46e9-413b-8061-54d52f655b67 type btrfs
(rw,nosuid,nodev,relatime,seclabel,space_cache=v2,subvolid=5,subvol=/)
We have subvolid and subvol "path".

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.

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
My naive guess would be string ordering "/dev/vdb1" is before "/dev/vdc1" or
"VirtIO_Disk_1" vs "VirtIO_Disk_2"

I don't know how to handle the multiple mountpoints for the same block :
    MountPoints:        /run/media/chris/b5c151d7-46e9-413b-8061-54d52f655b67
                        /run/media/chris/b5c151d7-46e9-413b-8061-54d52f655b671
                        /run/media/chris/b5c151d7-46e9-413b-8061-54d52f655b6710
[...]
                        /run/media/chris/b5c151d7-46e9-413b-8061-54d52f655b677
                        /run/media/chris/b5c151d7-46e9-413b-8061-54d52f655b678
                        /run/media/chris/b5c151d7-46e9-413b-8061-54d52f655b679

Should we expose only one ? Are they equivalent ?
Currently I believe solid just picks the first one.

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


More information about the kfm-devel mailing list