Fix for partition races #64
Conversation
…ions" This reverts commit eb4b994. The BLKRRPART ioctl is dangerous in that it causes pairs of remove/add uevents for all partitions which in turn confuse our internal data structures and cause the block devices to briefly disappear from the filesystem. Rereading the partition table is also unnecessary since parted, libblockdev, and udevd do that already. Thus, eb4b994 might actually make things worse instead of fixing the bug it is intended to fix.
This is hopefully a better fix than eb4b99 to https://bugs.freedesktop.org/show_bug.cgi?id=85477 https://bugs.debian.org/767457 https://launchpad.net/bugs/1460602
|
I have confirmed that this works via the https://github.com/cockpit-project/cockpit/blob/master/test/verify/check-storage-luks This test shows the following behavior on Debian unstable: With storaged 2.5.0: reliably fails This means that A consistent conclusion can be found with Fedora: With storaged 2.5.1: reliably fails |
|
Hm... Isn't this basically a workaround of an udev issue? Not that I would not want to merge the patch (thanks! btw.). Just trying to understand it... |
Yes, you could say that. Real fix 1: We can remove the BLKRRPART call from udev. This is a change in behavior and might break existing code. Real fix 2: We can change BLKRRPART to not remove everything and then put everything back, but instead to only add new partitions, and only remove partitions that have really disappeared. |
No description provided.