Re: [PATCH 1/2] btrfs-progs: Ignore path device during device scan

[Nikolay Borisov <nborisov@suse.com>]

On 29.09.21 г. 2:03, Anand Jain wrote:
> On 28/09/2021 20:37, Nikolay Borisov wrote:
>> Currently btrfs-progs will happily enumerate any device which has a
>> btrfs filesystem on it. For the majority of use cases that's fine and
>> there haven't been any problems with that.
> 
>> However, there was a recent
>> report
> 
>  Could you point to the report or if it is internal?

Internal

> 
>  Kernel message has the process of name for the device scan.
>  We don't have to fix the btrfs-progs end if it is not doing it.
> 
>> that in multipath scenario when running "btrfs fi show" after a
>> path flap 
> 
>  It is better to use 'btrfs fi show -m' it provides kernel perspective.

[146822.972653] BTRFS warning: duplicate device /dev/sdd devid 1
generation 8 scanned by systemd-udevd (6254)

[146823.060984] BTRFS info (device dm-0): devid 1 device path
/dev/mapper/3600140501cc1f49e5364f0093869c763 changed to /dev/dm-0
scanned by systemd-udevd (6266)

[146823.075084] BTRFS info (device dm-0): devid 1 device path /dev/dm-0
changed to /dev/mapper/3600140501cc1f49e5364f0093869c763 scanned by
systemd-udevd (6266)


btrfs fi show -m is actually consistent with always showing the mapper
device.

> 
>  What do you mean by path flap here? Do you mean a device-path in a
> multi-path config disappeared forever or failed temporarily?

flap means going up and down. The gist is that btrfs fi show would show
the latest device being scanned, which in the case of multipath device
could be any of the paths.

> 
>> instead of the multipath device being show the path device is
>> shown. So a multipath filesystem might look like:
>>
>> Label: none  uuid: d3c1261f-18be-4015-9fef-6b35759dfdba
>>     Total devices 1 FS bytes used 192.00KiB
>>     devid    1 size 10.00GiB used 536.00MiB path
>> /dev/mapper/3600140501cc1f49e5364f0093869c763
> 
>>
>> /dev/mapper/xxx can actually be backed by an arbitrary number of path,
> 
>  It is not arbitrary it depends on the number of HBAs configured to the
> storage/LUN in a SAN.

And this precisely means that the number of paths is arbitrary, based on
particular configuration.

> 
>> which in turn are presented to the system as ordinary scsi devices i.e
>> /dev/sdd.
> 

<snip>