On 10/2/19 5:55 PM, Andrei Borzenkov wrote:
On Wed, Oct 2, 2019 at 12:27 PM Anand Jain <anand.j...@oracle.com> 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.
