bug#25756: [systemd-devel] systemd mucking with partition tables ( was: bug#25756: Problems using "parted ... print" on nvme devices )

[Phil Susi]

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.