On Wed, Oct 2, 2019 at 1:19 PM Anand Jain <anand.jain@xxxxxxxxxx> wrote: > > > > On 10/2/19 6:02 PM, Anand Jain wrote: > > > > > > On 10/2/19 5:55 PM, Andrei Borzenkov wrote: > >> On Wed, Oct 2, 2019 at 12:27 PM Anand Jain <anand.jain@xxxxxxxxxx> wrote: > >>> > >>> > >>> > >>> I am looking for systemd part of the answers to understand what > >>> is triggering a strange problem. Any help is appreciated. > >>> > >>> After mkfs.btrfs creates btrfs filesystem it scans to register the > >>> device in btrfs.ko. > >>> And we have 'btrfs dev scan --forget' command to undo the process of > >>> register. > >>> > >>> But the problem is - immediately after 'btrfs dev scan --forget' the > >>> systemd-udevd scans the device again, defeating the purpose of the > >>> forget as show below (scanned-by). > >>> > >>> mkfs.btrfs -fq /dev/sdc && btrfs dev scan --forget /dev/sdc > >>> > >>> ------------------- > >>> kernel: BTRFS: device fsid 8ea20bb2-888a-4b3b-9f4c-1db9117dc219 devid 1 > >>> transid 5 /dev/sdc scanned-by mkfs.btrfs > >>> kernel: BTRFS: device fsid 8ea20bb2-888a-4b3b-9f4c-1db9117dc219 devid 1 > >>> transid 5 /dev/sdc scanned-by systemd-udevd > >>> ------------------- > >>> > >>> And the problem does _not_ happen if there is a sleep of 3 secs after > >>> the mkfs.btrfs, as below. > >>> > >>> mkfs.btrfs -fq /dev/sdc && sleep 3 && btrfs dev scan --forget /dev/sdc > >>> > >>> ------------------ > >>> kernel: BTRFS: device fsid 601bd01a-5e6b-488a-b020-0e7556c83087 devid 1 > >>> transid 5 /dev/sdc scanned-by mkfs.btrfs > >>> ------------------ > >>> > >>> Any idea what happening from the systemd point of view? > >>> > >> > >> run > >> > >> udevadm monitor -ku > >> > >> in both cases and post results. My educated guess is that udev scan is > >> in response to mkfs and you have unfortunate race condition here. > >> > > > > > > Looks like what is happening is .. > > > > . Change in fsid (by mkfs.btrfs) notifies and triggers systemd > > . Systemd checks if the device is ready by using > > BTRFS_IOC_DEVICES_READY. > > . However BTRFS_IOC_DEVICES_READY from systemd races with forget > > command and the result depends on who wins the race. > > > > > I get this for the command mkfs.btrfs: (for /dev/sdc) > > KERNEL[185263.634507] change > /devices/pci0000:5d/0000:5d:02.0/0000:65:00.0/host0/target0:2:2/0:2:2:0/block/sdc > (block) > UDEV [185263.637870] change > /devices/pci0000:5d/0000:5d:02.0/0000:65:00.0/host0/target0:2:2/0:2:2:0/block/sdc > (block) > KERNEL[185263.640572] change > /devices/pci0000:5d/0000:5d:02.0/0000:65:00.0/host0/target0:2:2/0:2:2:0/block/sdc > (block) > KERNEL[185263.641552] change > /devices/pci0000:5d/0000:5d:02.0/0000:65:00.0/host0/target0:2:2/0:2:2:0/block/sdc > (block) > UDEV [185263.644337] change > /devices/pci0000:5d/0000:5d:02.0/0000:65:00.0/host0/target0:2:2/0:2:2:0/block/sdc > (block) > UDEV [185263.647656] change > /devices/pci0000:5d/0000:5d:02.0/0000:65:00.0/host0/target0:2:2/0:2:2:0/block/sdc > (block) > > And no notification for mkfs.btrfs -fq /dev/sdb > > Looks like there is some rules set. But I don't find any rules > in /etc/udev/rules.d specific to /dev/sdb can it be set somewhere > else? > Default rules are in /usr/lib/udev, but rules can only block udev events (if at all), they have no impact on what kernel does. I guess util-linux would be a better place to ask about mkfs behavior.
