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

On Wed, 19.04.17 09:01, Phil Susi ([email protected]) wrote:

> On 2/16/2017 12:32 PM, Brian C. Lane wrote:
> > I think the tricky part of that is going to be that when we open the
> > device we don't really know what commands are going to be issued so it
> > needs to be RDWR to allow for all the other possibilities.
> 
> I'm sure I have seen a patch floating around somewhere and been meaning
> to merge it for some time that opens the device RO at first, then
> switches to RW if and when it is required.  We should do that, but...
> 
> > There should be some way to lock out udev during your tests.
> 
> Why the hell has udev started mucking with the partition tables and dev
> nodes every time someone opens the block device rw?  Parted and other
> partitioning tools have always manipulated the in memory partition table
> themselves after updating the disk, so why does systemd now think this
> is its responsibility?

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.

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. 

> Parted takes care to only manipulate the individual partitions that have
> changed, but I'm not sure that systemd doesn't just blow them all way
> and recreate them all, causing significant system wide disruption.
> There are some open bugs in Ubuntu for the unity desktop where drives
> you have unlocked from your hotbar reappear due to them being "removed"
> and reappearing due to this behavior.  systemd should stop this nonsense.

My recommendation: instead of calling the stuff we do "nonsense",
first figure out what is actually implemented.

Lennart