Re: "btrfs: harden agaist duplicate fsid" spams syslog

[David Sterba <dsterba@suse.cz>]

On Fri, Jul 12, 2019 at 02:32:10PM +0100, Graham Cobb wrote:
> It is weird, because there are other symlinks also pointing to the
> device. In my case, lvm sets up both /dev/mapper/cryptdata4tb--vg-backup
> and /dev/cryptdata4tb-vg/backup as symlinks to ../dm-13 but only the
> first one fights with /dev/dm-13 for the devid.

'btrfs' utility has code to canonicalize the device mapper names and use
only '/dev/mapper' and not /dev/dm-*, but I think systemd/udev has own
utility for device scanning that might not do the translation.

> > One fix for this is to make it a ratelimit print. But then the same
> > thing happens without notice. If you monitor /proc/self/mounts
> > probably you will notice that mount device changes every ~2mins.
> 
> I haven't managed to catch it. Presumably because, according to the
> logs, it seems to switch the devices back again within less than a second.

This looks like some device enumeration takes any name for a given
device and calls scan on it. I have seen that eg. systemd tries to
deactivate a swap partition by all names it found under /dev/disk/* .

> > I will be more keen to find the module which is causing this issue,
> > that is calling 'btrfs dev scan' every ~2mins or trying to mount
> > an unmounted device without understanding that its mapper is already
> > mounted.
> 
> Any ideas how we can determine that?
> 
> Can I try something like stopping udev for 5 minutes to see if it stops?
> Or will that break my system (I can't schedule any downtime until after
> I am back)? Note (in case it is relevant) this is a systemd system so
> udev is actually systemd-udevd.service.

'udevadm monitor' can tell something about the device changes.

We still don't understand what happens but I'm inclined to think that
the fix should be in btrfs scanning code to print the message only once
for a given device with the first name.

The device path must exist in system and can be always traced either to
the /dev/dm-* or to /dev/mapper name, so it's maybe a minor usability
issue expecing user to resolve the path to see the pretty name.