On Do, 10.04.25 12:47, Phillip Susi (ph...@thesusis.net) wrote: > It appears that udev calls BLKRRPRT on a block device whenever it gets > an inotify event that some other process has closed an fd to it.
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. > This causes all of the partitions on the disk to be deleted and ( > hopefully ) re-added. This makes for a lot of seemingly useless > udev events. 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? > Even if they are re-added, this causes a race with other processes on > the system and can cause them to error because the partition > disappeared. Worse yet, the kernel may not even be able to read the > partition table on the disk ( it may have been provided by command line > or use of the partx tool ), in which case, this would just delete the > partitions. 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. > Why does udev do this and could it stop? To robustly make sure the kernel and the on-disk partitions remain in sync. This is not new behaviour btw. It's widely documented (as above), and has been that way for decades. Lennart -- Lennart Poettering, Berlin
