On Wed, 19.04.17 09:01, Phil Susi (ps...@ubuntu.com) 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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel