[systemd-devel] [bug] strange systemd-udevd scan for btrfs device

Anand Jain anand.jain at oracle.com
Fri Oct 4 09:42:02 UTC 2019


use appropriate ml for systemd bugs
-systemd-bugs at lists.freedesktop.org
+systemd-devel at lists.freedesktop.org

inline below..

On 10/2/19 9:33 PM, Andrei Borzenkov wrote:
> On Wed, Oct 2, 2019 at 1:19 PM Anand Jain <anand.jain at oracle.com> 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 at 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.
>>>
>>
>>
>> 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.
> 



In the event of a mkfs.btrfs on a device the udev action to scan
the device into the btrfs kernel is redundant !. because mkfs.btrfs
is already doing it.

/usr/lib/udev has quite a lot of rules.
Now how do I find why udev has an rule for sdc and not for sdb.
There isn't any obvious things I found in /usr/lib/udev for sdc/sdb.

Thanks, Anand


More information about the systemd-devel mailing list