On Wed, Sep 29, 2021 at 09:59:15AM +0300, Nikolay Borisov wrote:

On 29.09.21 г. 2:03, Anand Jain wrote:

quoted

On 28/09/2021 20:37, Nikolay Borisov wrote:

quoted

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.

quoted

However, there was a recent
report

 Could you point to the report or if it is internal?

Internal

quoted

 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.

quoted

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.

quoted

 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.

Please use a more verbose description like

  "a path can flap (go up and down)"