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

[Graham Cobb <g.btrfs@cobb.uk.net>]

On 12/07/2019 13:46, Anand Jain wrote:
> I am unable to reproduce, I have tried with/without dm-crypt on both
> oraclelinux and opensuse (I am yet to try debian).

I understand. I am going to be away for a week but I am happy to look
into trying to create a smaller reproducer (for example in a vm) once I
get back.

> The patch in $subject is fair, but changing device path indicates
> there is some problem in the system. However, I didn't expect
> same device pointed by both /dev/dm-x and /dev/mapper/abc would
> contended.

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.

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

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

Thanks
Graham