Lennart Poettering <lenn...@poettering.net> writes: > Not quite. it will issue that when a process closes the block device > after it was open for *write*. That's a relevant > distinction. Typically, userspace tools only open raw block devices > only to partition/format file systems for write, and thus if we then > reread the partition table we'll quickly notice the changes and make > sure they are reflected in the kernel device table.
The partitioning tool has already taken care of updating the kernel parition table; there is no reason for udev to redo this. In fact, it will fail to do so if some other partition on the disk is open ( or mounted ). > Why are they useless? if you change the superblock or partition table > we'll reread things exactly once. if you see a ton more of these > events this is probably triggered by some broken tool not keeping open > an fd, but closing/reopening them all the time for each write? Say you have 12 partitions and add a new one. You get one ADD event for the new partition, and that is all you should need. Then udev triggers 13 remove and 13 add events to put things right back where they were. Or if instead of adding you resize one partition. Then you get the CHANGE event on that partition, followed by a dozen REMOVE and ADD. Now if you are shrinking a partition to make room to add a new one, instead of just getting a CHANGE and an ADD event, you get multiple rounds of udev triggering a dozen delete+add events. > Please have a look at: https://systemd.io/BLOCK_DEVICE_LOCKING > > Repartitioning tools can take a BSD file lock on the main block device (not > the partition devices!) and udev will not reprobe things as long as > the file lock is taken. Yep... you've mentioned that before. Doing that might take care of the race condition, so I'll try to look into that. It does not help though when the kernel does not recognize the partition table. In that case, the partitioning tool took care of informing the kernel about the partitions, then udev tosses them out. Parted understands many esoteric partition table formats that I believe even distgribution kernels often do not enable ( Amiga comes to mind ). In this situation, people can run partprobe to recognize the partitions, but then udev calls BLKRRPRT and they get thrown out. BLKRRPRT is an old, blunt footgun whose use should be eliminated.
