* [bug] strange systemd-udevd scan for btrfs device
@ 2019-10-02 9:25 Anand Jain
2019-10-02 9:55 ` Andrei Borzenkov
0 siblings, 1 reply; 6+ messages in thread
From: Anand Jain @ 2019-10-02 9:25 UTC (permalink / raw)
To: systemd-bugs; +Cc: linux-btrfs
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?
Thanks, Anand
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bug] strange systemd-udevd scan for btrfs device
2019-10-02 9:25 [bug] strange systemd-udevd scan for btrfs device Anand Jain
@ 2019-10-02 9:55 ` Andrei Borzenkov
2019-10-02 10:02 ` Anand Jain
0 siblings, 1 reply; 6+ messages in thread
From: Andrei Borzenkov @ 2019-10-02 9:55 UTC (permalink / raw)
To: Anand Jain; +Cc: systemd-bugs, Btrfs BTRFS
On Wed, Oct 2, 2019 at 12:27 PM Anand Jain <anand.jain@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bug] strange systemd-udevd scan for btrfs device
2019-10-02 9:55 ` Andrei Borzenkov
@ 2019-10-02 10:02 ` Anand Jain
2019-10-02 10:19 ` Anand Jain
0 siblings, 1 reply; 6+ messages in thread
From: Anand Jain @ 2019-10-02 10:02 UTC (permalink / raw)
To: Andrei Borzenkov; +Cc: systemd-bugs, Btrfs BTRFS
On 10/2/19 5:55 PM, Andrei Borzenkov wrote:
> On Wed, Oct 2, 2019 at 12:27 PM Anand Jain <anand.jain@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bug] strange systemd-udevd scan for btrfs device
2019-10-02 10:02 ` Anand Jain
@ 2019-10-02 10:19 ` Anand Jain
2019-10-02 13:33 ` Andrei Borzenkov
0 siblings, 1 reply; 6+ messages in thread
From: Anand Jain @ 2019-10-02 10:19 UTC (permalink / raw)
To: Andrei Borzenkov; +Cc: systemd-bugs, Btrfs BTRFS
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@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?
Thanks, Anand
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bug] strange systemd-udevd scan for btrfs device
2019-10-02 10:19 ` Anand Jain
@ 2019-10-02 13:33 ` Andrei Borzenkov
2019-10-04 9:42 ` Anand Jain
0 siblings, 1 reply; 6+ messages in thread
From: Andrei Borzenkov @ 2019-10-02 13:33 UTC (permalink / raw)
To: Anand Jain; +Cc: systemd-bugs, Btrfs BTRFS
On Wed, Oct 2, 2019 at 1:19 PM Anand Jain <anand.jain@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@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bug] strange systemd-udevd scan for btrfs device
2019-10-02 13:33 ` Andrei Borzenkov
@ 2019-10-04 9:42 ` Anand Jain
0 siblings, 0 replies; 6+ messages in thread
From: Anand Jain @ 2019-10-04 9:42 UTC (permalink / raw)
To: Andrei Borzenkov, systemd-devel; +Cc: Btrfs BTRFS
use appropriate ml for systemd bugs
-systemd-bugs@lists.freedesktop.org
+systemd-devel@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@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@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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-10-04 9:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-02 9:25 [bug] strange systemd-udevd scan for btrfs device Anand Jain
2019-10-02 9:55 ` Andrei Borzenkov
2019-10-02 10:02 ` Anand Jain
2019-10-02 10:19 ` Anand Jain
2019-10-02 13:33 ` Andrei Borzenkov
2019-10-04 9:42 ` Anand Jain
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).