I've investigate myself what uevent are sent after each command. I use "udevadm monitor" to watch the event sent from kernel.
The experiment starts from removing the existing device but if it's placed at last, the uevents are the same. What's very curious to me is that the ACTION!="remove" in my rule only ignores the uevent from dd but the rest effects. The uevent after dmsetup resume is considered even though the uevent shapes the same as dd. All I want to do is suppress the read after these commands. I think it's health check by reading randomly chosen blocks. I've observed that more than 100 of 4KB reads are submitted to my logical device after creation and that hinders my tests as they expect these extra IOs aren't existing. (more precisely saying it's not black box test but white box that uses the internal stats in assertions) # dmsetup remove KERNEL[4202.177671] remove /devices/virtual/block/dm-0 (block) KERNEL[4202.205822] remove /kernel/slab/dmwb_buf_8 (slab) KERNEL[4202.206786] remove /kernel/slab/bio-3 (slab) KERNEL[4202.250279] remove /devices/virtual/bdi/251:0 (bdi) KERNEL[4202.250776] remove /devices/virtual/block/dm-0 (block) # dmsetup create KERNEL[4226.692607] add /devices/virtual/bdi/251:0 (bdi) KERNEL[4226.692852] add /devices/virtual/block/dm-0 (block) KERNEL[4226.695092] add /kernel/slab/dmwb_buf_8 (slab) KERNEL[4229.107766] add /kernel/slab/bio-3 (slab) # dd (write) KERNEL[4229.108196] change /devices/virtual/block/dm-0 (block) # dmsetup suspend # dmsetup resume KERNEL[4271.409068] change /devices/virtual/block/dm-0 (block) - Akira _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel