Right. It happened even without this patch but we just know it now.
In the original investigations of the patch, the moment you copy a device image into another device, the autoscan would scan the new device into the btrfs kernel and created a mess. Now with this patch we won't replace the device path unless it's the same device (and we have to let that happen). Now the question I am trying to understand, why same device is being scanned every 2 mins, even though its already mount-ed. I am guessing its toggling the same device paths trying to mount the device-path which is not mounted. So autofs's check for the device mount seems to be path based. Would you please provide your LVM configs and I believe you are using dm-mapping too. What are the device paths used in the fstab and in grub. And do you see these messages for all devices of 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 or just devid 4? Would you please provide more logs at least a complete cycle of the repeating logs. -Anand On 11/7/19 2:49 AM, Graham Cobb wrote:
Anand's Nov 2018 patch "btrfs: harden agaist duplicate fsid" has recently percolated through to my Debian buster server system. And it is spamming my log files. Each of my btrfs filesystem devices logs 4 messages every 2 minutes. Here is an example of the 4 messages related to one device: Jul 10 19:32:27 black kernel: [33017.407252] BTRFS info (device sdc3): device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved old:/dev/mapper/cryptdata4tb--vg-backup new:/dev/dm-13 Jul 10 19:32:27 black kernel: [33017.522242] BTRFS info (device sdc3): device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved old:/dev/dm-13 new:/dev/mapper/cryptdata4tb--vg-backup Jul 10 19:32:29 black kernel: [33018.797161] BTRFS info (device sdc3): device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved old:/dev/mapper/cryptdata4tb--vg-backup new:/dev/dm-13 Jul 10 19:32:29 black kernel: [33019.061631] BTRFS info (device sdc3): device fsid 4d1ba5af-8b89-4cb5-96c6-55d1f028a202 devid 4 moved old:/dev/dm-13 new:/dev/mapper/cryptdata4tb--vg-backup What is happening here is that each device is actually an LVM logical volume, and it is known by a /dev/mapper name and a /dev/dm name. And every 2 minutes something cause btrfs to notice that there are two names for the same device and it swaps them around. Logging a message to say it has done so. And doing it 4 times. I presume that the swapping doesn't cause any problem. I wonder slightly whether ordering guarantees and barriers all work correctly but I haven't noticed any problems. I also assume it has been doing this for a while -- just silently before this patch came along. Is btrfs noticing this itself or is something else (udev or systemd, for example) triggering it? Should I worry about it? Is there any way to not have my log files full of this? Graham [This started with a Debian testing kernel a couple of months ago. Current uname -a gives: Linux black 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux]
