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
