On Thu, Oct 12, 2017 at 7:01 PM, Akira Hayakawa <ruby.w...@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 <graw...@gmail.com>
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel