On 4/19/2017 12:17 PM, Lennart Poettering wrote: > This isn't precisely new functionality, it has been doing that since > years. It will synthesize "change" udev events when a process closes a block > device after writing, so that the changed superblock/partition > information is properly propagated to clients. > > Also note that parted never was in the business of retriggering block > devices through sysfs/udev (i.e. echoing "change" into a "uevents" > file in sysfs), only udev ever did that so far, and I am pretty sure > that should stay that way.
What? The kernel must generate the event as otherwise systemd has no idea that a process on the system closed its handle to the device, and so would not know when it should trigger them. Or do you mean that the kernel only triggers on the main device, and udev now synthesizes events on the partitions? That could explain why udevadm monitor is now showing me KERNEL change events on the partitions as well, unless the kernel itself really is generating those internally? I'm fairly certain these events on the partition devices did not used to happen, and they should not be happening now. Changing one partition should not cause a change event on another partition that has not been changed in any way. > As long as there's a BSD lock in effect on a block device, udev won't > synthesize such events. Hence: if you want to make a series of > changes, and want to close the block device fds in the process, then > make sure to keep at least one fd open with a BSD lock in effect, and > your changes won't be propagated into udev events until you release > it. The timing isn't the issue, so using a lock to delay does not help.
