[systemd-devel] How to stop systemd-udevd reading a device after dd

Mantas Mikul─Śnas grawity at gmail.com
Fri Oct 13 05:06:10 UTC 2017

On Thu, Oct 12, 2017 at 7:01 PM, Akira Hayakawa <ruby.wktk at gmail.com> wrote:

> I have a device /dev/sdb1 and let's trace the block request by blktrace
> $ sudo blktrace -d /dev/sdb1
> When I write 4KB using dd
> $ sudo dd if=/dev/zero of=/dev/sdb1 oflag=direct bs=4k count=1
> The block trace (after blkparsed) is write request as expected
>   8,17   2        2     0.000003171  5930  Q  WS 2048 + 8 [dd]
> followed by a unexpected read from systemd-udevd
>   8,17   7        2     0.001755563  5931  Q   R 2048 + 8 [systemd-udevd]
> My first question is what is: this read request?

When a device node is closed for writing, the kernel generates a 'change'
uevent for it. This prompts udev to re-read filesystems and update its
cache of labels, UUIDs, and other information. Tools like `lsblk` or
/dev/disk/by-{id,uuid,label}/* use the udev database.

And I want to stop the read request because it makes it difficult to test
> kernel code.
> So the second question is: how can I stop the read request?

gparted seems to achieve this by masking all .rules files it can find (by
creating 0-byte versions under /run/udev/rules.d).

Not sure what else to recommend. I thought there used to be inhibit mode
under `udevadm control`, but I can't find it anymore.

> Actually I found this behavior when I test my module https://github.com/
> akiradeveloper/dm-writeboost
> Since I need to create/remove devices during the tests, there is no choice
> to stop udev.service.

The kernel itself adds/removes device nodes under /dev. Udev only manages
auxiliary stuff like symlinks (like /dev/disk/by-*), permissions, and such.
So you *could* survive without udev in case of emergency.

Mantas Mikul─Śnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20171013/7a7c2791/attachment.html>

More information about the systemd-devel mailing list