Bug 427092

Created attachment 131997 [details]
screenshot of problem

- there should be one icon per file system rather than one icon per device

- as a consequence of showing an icon per device, a click on each icon results in a request to mount that specific node, which just adds more mountpoints (file system is mounted multiple times)

lsblk

vdb    252:16   0  100G  0 disk 
└─vdb1 252:17   0  100G  0 part /run/media/chris/braid113
vdc    252:32   0  100G  0 disk 
└─vdc1 252:33   0  100G  0 part 
vdd    252:48   0  100G  0 disk 
└─vdd1 252:49   0  100G  0 part 

I've clicked on vdc1 and vdd1 icons a few times, and what happens is udisksd keeps mounting additional instances.

# mount (filtered)

/dev/vdb1 on /run/media/chris/braid1 type btrfs (rw,nosuid,nodev,relatime,seclabel,space_cache,subvolid=5,subvol=/)
/dev/vdb1 on /run/media/chris/braid11 type btrfs (rw,nosuid,nodev,relatime,seclabel,space_cache,subvolid=5,subvol=/)
/dev/vdb1 on /run/media/chris/braid12 type btrfs (rw,nosuid,nodev,relatime,seclabel,space_cache,subvolid=5,subvol=/)
/dev/vdb1 on /run/media/chris/braid13 type btrfs (rw,nosuid,nodev,relatime,seclabel,space_cache,subvolid=5,subvol=/)
/dev/vdb1 on /run/media/chris/braid14 type btrfs (rw,nosuid,nodev,relatime,seclabel,space_cache,subvolid=5,subvol=/)
/dev/vdb1 on /run/media/chris/braid15 type btrfs (rw,nosuid,nodev,relatime,seclabel,space_cache,subvolid=5,subvol=/)
/dev/vdb1 on /run/media/chris/braid16 type btrfs (rw,nosuid,nodev,relatime,seclabel,space_cache,subvolid=5,subvol=/)
/dev/vdb1 on /run/media/chris/braid17 type btrfs (rw,nosuid,nodev,relatime,seclabel,space_cache,subvolid=5,subvol=/)
/dev/vdb1 on /run/media/chris/braid18 type btrfs (rw,nosuid,nodev,relatime,seclabel,space_cache,subvolid=5,subvol=/)
/dev/vdb1 on /run/media/chris/braid19 type btrfs (rw,nosuid,nodev,relatime,seclabel,space_cache,subvolid=5,subvol=/)
/dev/vdb1 on /run/media/chris/braid110 type btrfs (rw,nosuid,nodev,relatime,seclabel,space_cache,subvolid=5,subvol=/)
/dev/vdb1 on /run/media/chris/braid111 type btrfs (rw,nosuid,nodev,relatime,seclabel,space_cache,subvolid=5,subvol=/)
/dev/vdb1 on /run/media/chris/braid112 type btrfs (rw,nosuid,nodev,relatime,seclabel,space_cache,subvolid=5,subvol=/)
/dev/vdb1 on /run/media/chris/braid113 type btrfs (rw,nosuid,nodev,relatime,seclabel,space_cache,subvolid=5,subvol=/)

Created attachment 131998 [details]
udisks messages when clicking on each icon

kernel 5.8.11-300.fc33.x86_64

udisks2-2.9.1-1.fc33.x86_64

Could you run and paste here or attach the result of the command:

solid-hardware5 list | grep braid1

(The originally reported test setup is gone (it's a VM), so I have another setup based on Fedora-KDE-Live-x86_64-Rawhide-20201206.n.1.iso and a 2x btrfs raid1.)

$ ls -l /dev/disk/by-label/
total 0
lrwxrwxrwx. 1 root root 10 Dec  7 13:59 braid1 -> ../../vdc1
lrwxrwxrwx. 1 root root 10 Dec  7 13:56 fedora_localhost-live -> ../../vda3
$ solid-hardware5 list | grep braid1
$ sudo solid-hardware5 list | grep braid1
$

I get nothing for that command. I'll attach the full list without filter.

Created attachment 133925 [details]
solid-hardware5 list

Created attachment 133926 [details]
udisksctl dump

(In reply to Chris Murphy from comment #7)
> (The originally reported test setup is gone (it's a VM), so I have another
> setup based on Fedora-KDE-Live-x86_64-Rawhide-20201206.n.1.iso and a 2x
> btrfs raid1.)
> 
> $ ls -l /dev/disk/by-label/
> total 0
> lrwxrwxrwx. 1 root root 10 Dec  7 13:59 braid1 -> ../../vdc1
> lrwxrwxrwx. 1 root root 10 Dec  7 13:56 fedora_localhost-live -> ../../vda3
> $ solid-hardware5 list | grep braid1
> $ sudo solid-hardware5 list | grep braid1
> $
> 
> I get nothing for that command. I'll attach the full list without filter.

Thanks.

Could you run and copy results of :

solid-hardware5 details '/org/freedesktop/UDisks2/block_devices/vdc1'
solid-hardware5 details '/org/freedesktop/UDisks2/block_devices/vdc'
solid-hardware5 details '/org/freedesktop/UDisks2/block_devices/vda3'
solid-hardware5 details '/org/freedesktop/UDisks2/block_devices/vda2'
solid-hardware5 details '/org/freedesktop/UDisks2/block_devices/vda1'
solid-hardware5 details '/org/freedesktop/UDisks2/block_devices/vda'
solid-hardware5 details '/org/freedesktop/UDisks2/drives/VirtIO_Disk_1'
solid-hardware5 details '/org/freedesktop/UDisks2/drives/VirtIO_Disk_2'
solid-hardware5 details '/org/freedesktop/UDisks2/drives/VirtIO_Disk'

On your system what are the path and names of duplicated btrfs disk you see in dolphin ?

I am optimitic that that plus the udisksctl dump should pinpoint the way for a fix.

Created attachment 134134 [details]
udisksctl dump 2

Created attachment 134135 [details]
solid-hardware5 details 2

Unfortunately I forgot to label this 2-drive Btrfs file system, so it has no label in the "2" version of attached udisksctl dump and sh5 details.

It appears as two "Linux filesystem" icons with a small orange/red symbol on the lower left corner, in Dolphin. And it doesn't automount, but if I click on either one, it mounts the btrfs file system correctly, it just looks odd to see two icons for the same file system, i.e. somehow dedup for the same file system UUID? e.g. in this case from blkid:

/dev/vdb1: UUID="b5c151d7-46e9-413b-8061-54d52f655b67" UUID_SUB="22d9fd70-0b6b-4720-879c-7186d5c47abf" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="Linux filesystem" PARTUUID="ea70e8dc-ac59-44b2-8e98-a77b49505611"
/dev/vdc1: UUID="b5c151d7-46e9-413b-8061-54d52f655b67" UUID_SUB="0d9e14e0-20fb-4c6c-bf3a-eb17cce88a7f" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="Linux filesystem" PARTUUID="996e199c-0ed2-4ed5-beda-a64d2823


If I click the first drive icon, its actually the icon below it that appears to get mounted. The icon I click on still has the "not mounted" symbol. The drive icon below it no longer has the "not mounted" symbol. Path to the file system mount is:

/run/media/chris/b5c151d7-46e9-413b-8061-54d52f655b67

I'm not at all certain about the proper way to handle it but maybe dedup by UUID? Btrfs doesn't care which /dev/ node is used for mounting. And also the mount command can accept a UUID directly as well as by /dev/disk/by-uuid/...

Possibly such functionality belongs in udisksd, if it's the service being requested to do the mount.

(In reply to Chris Murphy from comment #13)
> Unfortunately I forgot to label this 2-drive Btrfs file system, so it has no
> label in the "2" version of attached udisksctl dump and sh5 details.
> 
> It appears as two "Linux filesystem" icons with a small orange/red symbol on
> the lower left corner, in Dolphin. And it doesn't automount, but if I click
> on either one, it mounts the btrfs file system correctly, it just looks odd
> to see two icons for the same file system, i.e. somehow dedup for the same
> file system UUID? e.g. in this case from blkid:
> 
> /dev/vdb1: UUID="b5c151d7-46e9-413b-8061-54d52f655b67"
> UUID_SUB="22d9fd70-0b6b-4720-879c-7186d5c47abf" BLOCK_SIZE="4096"
> TYPE="btrfs" PARTLABEL="Linux filesystem"
> PARTUUID="ea70e8dc-ac59-44b2-8e98-a77b49505611"
> /dev/vdc1: UUID="b5c151d7-46e9-413b-8061-54d52f655b67"
> UUID_SUB="0d9e14e0-20fb-4c6c-bf3a-eb17cce88a7f" BLOCK_SIZE="4096"
> TYPE="btrfs" PARTLABEL="Linux filesystem"
> PARTUUID="996e199c-0ed2-4ed5-beda-a64d2823
> 
> 
> If I click the first drive icon, its actually the icon below it that appears
> to get mounted. The icon I click on still has the "not mounted" symbol. The
> drive icon below it no longer has the "not mounted" symbol. Path to the file
> system mount is:
> 
> /run/media/chris/b5c151d7-46e9-413b-8061-54d52f655b67
> 
> I'm not at all certain about the proper way to handle it but maybe dedup by
> UUID? Btrfs doesn't care which /dev/ node is used for mounting. And also the
> mount command can accept a UUID directly as well as by /dev/disk/by-uuid/...
> 
> Possibly such functionality belongs in udisksd, if it's the service being
> requested to do the mount.

Once the filesystem is mounted how are the `solid-hardware5 details` and `udisckctl` like ?

Does umount work ?

I guess we can dedup by FS UUID, which one to select though, maybe naively the first one is enough.

udisksd is the service used to do the mount, so it seems any value we choose should work.

(In reply to Méven Car from comment #14)
> Does umount work ?

From Dolphin? Sorta. Check the screen shot. There are three identically named drives, two are unmounted, one mounted. I have to know that I need to click on the mounted one to unmount. But if I've gotten confused for whatever reason, and have clicked multiple times on any of the unmounted ones, udisks will succeed in mounting the file system multiple times at different locations each time. Once in this situation it's not obvious that it's even happened without going to the CLI, and also not obvious how to get out of the situation, i.e. properly umount.

Created attachment 134161 [details]
solid-hardware5 details, mounted once

Created attachment 134162 [details]
udisk dump, mounted once

Created attachment 134163 [details]
solid-hardware5 details, mounted multiple

To mount multiple times, just click on the unmounted disk icon in Dolphin many times. Why do this? Well, I want to see the files on that disk, and no files appear so I just start clicking and each time behind the scenes it's getting mounted but I still see nothing. I have to click on the disk icon that indicates it's mounted to see files.

Created attachment 134164 [details]
udisk dump, mounted multiple

>Possibly such functionality belongs in udisksd, if it's the service being requested to do the mount.

A possibly complicating factor is that it's legit to mount a Btrfs file system more than one time, e.g. 
mount -o subvol=accounting /dev/vdc1 /mnt/accounting
mount -o subvol=photos /dev/vdc1 /mnt/photos

In effect, all btrfs mounts are bind mounts, even without this option because it's always implied.

A mount without -o subvol means "use the default subvolume" which out of the box is an unnamed subvolume created at mkfs time, and can't be renamed or deleted. It's also called the "top-level" of the file system. The subvolume mounted by default can be changed using 'btrfs subvolume set-default', which leads to the case of how do you get back to this invisible "top-level" file system subvolume? These are equivalents:

mount -o subvol=/ /dev/vdc1 /mnt
mount -o subvolid=5 /dev/vdc1 /mnt
mount -o subvolid=0 /dev/vdc1 /mnt

This is why in the mount command at the top of ' solid-hardware5 details, mounted multiple' attachment, you see 'subvolid=5,subvol=/'

Btrfs is a file system of btrees, they each have a number, and the original design made the file btree id 5. And then soon after it was aliased to 0 to make it easier to remember I guess. Anyway, all subsequently created subvolume, and subvolume snapshots, are additional file btrees. Hence all of them can be mounted in this fashion, depending on layout preference.
https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout

But that doesn't really answer the question how to handle this case. All the desktops have some variation on this problem, which suggests a need for a common way to handle it if possible.

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.

> 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".

First step in udisks for duplicate mount points, and possible way forward for additional work needed:
https://github.com/storaged-project/udisks/pull/838
https://gitlab.gnome.org/GNOME/gvfs/-/issues/519#note_1016994

There is quite a bit of information about a Btrfs file system in sysfs, once it's mounted: /sys/fs/btrfs/$UUID/ including the number of and path to devices.

Hello 

I have the same problem. as this bug still exists I'd like to add info:

1. this might be a bug of KDE. this does not happen with linuxmint-cinnamon. which I used previously for a long time.
2. I tried to reproduce the behaviour without encryption, but dolphin just mounted the raid as expected.
2. I mounted my encrypted btrfs raid1 some minutes ago. right now there are 1015 different mountpoints in /run/media/username/.... 
3. this seems to slow down Dolphin.
4. unmounting does not work for me
5. I will add my steps to reproduce the behaviour, I hope this helps to resolve the issue and I hope i got everything right below:

#----------------------------
#expected behaviour:
#after 3x entering the passphrase, the btrfs raid1 is mounted only 1x as any other device.

#workaround: mount manually as root. something like
#  mount <one of the three unencrypted btrfs raid1 devices> mnt
#works.

#steps to reproduce 100+ unwanted mountpoints:
#-part1-setup,
#-part2-dolphin,
#-part3-show 100+ mountpoints

#----------------------------
#part1: setup loop devices
#----------------------------
#danger: please protect your data! use a VM or something

# 3x allocate 1G
# add partition table and one partition
# create a loop device
for ii in A B C; do fallocate -l 1G $ii; parted $ii mklabel gpt; parted $ii mkpart p${ii} btrfs 0% 100%; sudo losetup --show --find $ii; done

#passphrase will be 0000
echo -n 0000 > keyfile

#list loop device mappings
losetup -a
#lets assume its /dev/loop0 /dev/loop1 /dev/loop2 from now on!

#partprobe and then format as luks encrypted
for ii in 0 1 2; do sudo partprobe /dev/loop${ii}; sudo cryptsetup luksFormat /dev/loop${ii}p1 keyfile; done

#open and map to /dev/mapper/A_map etc.
sudo cryptsetup --key-file keyfile luksOpen /dev/loop0p1 A_map
sudo cryptsetup --key-file keyfile luksOpen /dev/loop1p1 B_map
sudo cryptsetup --key-file keyfile luksOpen /dev/loop2p1 C_map

#format for btrfs raid1
sudo mkfs.btrfs -L test -d raid1 -m raid1 -f /dev/mapper/A_map /dev/mapper/B_map /dev/mapper/C_map

#close/unmap encrypted partitions 
sudo cryptsetup close /dev/mapper/A_map
sudo cryptsetup close /dev/mapper/B_map
sudo cryptsetup close /dev/mapper/C_map

#partprobe again, dont know if needed
for ii in 0 1 2; do sudo partprobe /dev/loop${ii};

#----------------------------
#part2: dolphin interaction
#----------------------------

#close all dolphin windows
#open a dolphin window
#you should see 3x p1 under 'devices'
#click on each of the three p1 enter 0000 as passphrase -> error mounting. this is ok, as all 3 devices need to be opened for btrfs to mount them

#now under devices you should see 3x 'test'
#click on one of them to mount. it should be an empty directory.

#----------------------------
#part3: list mountpoints
#----------------------------
mount

#there should now be 100+ mountpoints for testXXXX
#unmounting is not always easy...

(In reply to Peter from comment #25)
> #workaround: mount manually as root. something like
> #  mount <one of the three unencrypted btrfs raid1 devices> mnt
> #works.
There is no need for root. you can just run
udisksctl mount -b <one of the three unencrypted btrfs raid1 devices>

Note that there is a chance (n-1)/n that the mounted fs will be represented by a device other than the one you passed to udisksctl. In that case udisksctl (or dolphin) will ask you for a password to unmount it, which is a bit annoying.

I rarely mount anything using dolphin nowadays, because in most of my cases (I use raid1 regularly) it's a very bad idea to do that. Instead I use udisksctl directly a lot.

Created attachment 161861 [details]
Screenshot of the drives shown in dolphin

The same behavior can be seen with bcachefs when I combine two drives into RAID 0. The 2.7 TiB drive being the background target and the 931.5 GiB drive being the foreground and promote targets. If I do df -T, the drives are shown correctly as combined

$ df -T
Filesystem            Type      Size  Used Avail Use% Mounted on
dev                   devtmpfs   12G     0   12G   0% /dev
run                   tmpfs      12G  2.0M   12G   1% /run
efivarfs              efivarfs  128K   56K   68K  45% /sys/firmware/efi/efivars
/dev/nvme1n1p2        btrfs     100G   58G   41G  59% /
tmpfs                 tmpfs      12G  366M   12G   4% /dev/shm
tmpfs                 tmpfs      12G   27M   12G   1% /tmp
/dev/nvme1n1p3        btrfs     377G  286G   91G  76% /home
/dev/nvme1n1p1        vfat      511M  292K  511M   1% /efi
/dev/sdb1             btrfs     1.9T  794G  1.1T  43% /mnt/Storage2T
/dev/sdd1             btrfs     932G  563G  369G  61% /mnt/WD1TB
/dev/sda1             btrfs     932G  694G  236G  75% /mnt/GameStorage1T
tmpfs                 tmpfs     2.4G  116K  2.4G   1% /run/user/1000
/dev/nvme0n1:/dev/sdc bcachefs  3.4T  1.3T  2.1T  39% /mnt/bcachefs