On Di, 06.05.25 13:03, Phillip Susi (ph...@thesusis.net) wrote: > 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.
Maybe in your case, in the general case that's not so however. People often dd images to disks, and hence it's essential the partitions show up once that's complete. And sure, this might not work if the disk is still in use, but that's fine: if a tool makes changes to the raw disk while it is used it better carefully makes sure to keep things "clean" and not interfere with the current users, it's on them to ensure that. But if it's not used, then udev can ensure that things are reset reasonably to kernel defaults, and noone should care, because noone is using it apparently. > > 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. I think it would be great if the kernel could optimize this, i.e. suppress remove/add events if the old and the new partition table match. But until then I think re-reading the partition table is still the right thing, to ensure kernel and on-disk structures are in sync. If this was an inner loop thing, i.e. happen regularly I'd be more concerned, but this is not a common code path, hence should not really be an issue. > > 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. Well, we live in a wolrd where the kernel partition scanner is the primary way to scan partitions, and we really care a lot about ensuring that if the block device is not otherwise blocked the kernel and on-disk format match, and that always, and uniformly, regardless if you freshly plugged in your device, or if you just dd'ed something onto it, or if you just exited your partitioning tool. If you want to do userspace partition scanning, then this would need some kernel changes first (because you'd have to turn off the kernel's own scanner, so that you don#t race against that), and you'd have to call your tool from udev, so that it always is run when a device pops up. As long as your do your changes from your own tool, that is called independently of that you should really take the lock to indicate clearly you want no interference, and we'll accept that and respect it. But if you give up all locks then the kernel's and udev's management takes control again. I think that's a very reasonable approach. Lennart -- Lennart Poettering, Berlin
