Re: [PATCH RFC] btrfs: pick device with lowest devt for show_devname

[Goffredo Baroncelli <kreijack@libero.it>]

On 27/11/2023 12.48, Anand Jain wrote:
> 
> 
> On 11/25/23 09:09, Anand Jain wrote:
[...]
>> I am skeptical about whether we have a strong case to create a single
>> pseudo device per multi-device Btrfs filesystem, such as, for example
>> '/dev/btrfs/<fsid>-<random>/rootid=5' and which means pseudo device
>> will carry the btrfs-magic and the actual blk devices something else.
>>
>> OR for now, regarding the umount issue mentioned above, we just can
>> document it for the users to be aware of.
>>
>> Any feedback is greatly appreciated.
>>
> 
> How about if we display the devices list in the options, so that
> user-land libs have something in the mount-table that tells all
> the devices part of the fsid?
> 
> For example:
> $ cat /proc/self/mounts | grep btrfs
> 
> /dev/sda1 /btrfs btrfs rw,relatime,space_cache=v2,subvolid=5,subvol=/,device=/dev/sda2,device=/dev/sdb3  0 0
> 

When I developed code to find a btrfs mount point from a disk, I had to
consider all the devices involved and check if one is in /proc/self/mounts.

Putting the devices list as device=<xxx>,device=<yyy> doesn't change anything because
the code has to manage a btrfs filesistem as "special" in any case.
To get the map <btrfs-uuid> <-> <devices-list> I used libblkid.

I think that a "saner" way to manage this issue, is to patch "mount" to
consider the special needing of btrfs.

Pay attention to consider also events like, removing a device, adding a device:
after these events how /dev/disk/by-uuid/ would be updated ?

What about bcachefs ? Does it have the same issue ? If yes this may be
a further reason to patch "mount" instead relying to a rule (pick the
lowest devt) spread for all the projects (systemd, mount...).

> Thanks.
> 

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5