On Tue, 2017-08-29 at 17:42 +0000, Don Brace wrote: > From: Don Brace > > [ ... ] > > Hello Don, > > > > Can you have another look at the udev rules on your test system? The last > > rule in 60-block.rules looks like a watch rule to me. The same holds for the > > upstream version of that file > > (https://github.com/systemd/systemd/blob/maste > > r/rules/60-block.rules). > > > > Bart. > > It is a watch rule. > > systemd/src/udev/udevd.c > manager_new > manager->fd_inotify = udev_watch_init(manager->udev); > sd_event_add_io(manager->event, &manager->inotify_event, manager->fd_inotify, EPOLLIN, on_inotify, manager); > on_inotify (systemd source code: src/udev/udevd.c) > synthesize_change > ioctl --> BLKRRPART > > This rule ends up calling BLKRRPART. Hello Don, Sorry if I'm slow today, but it's not clear to me how the BLKRRPART ioctl triggers a change of max_sectors_kb? And even if it really is this ioctl that triggers a change of max_sectors_kb, should the kernel code that handles max_sectors_kb writes be modified or should rather a udev rule be added that sets max_sectors_kb to the desired value after each partition rescan? Thanks, Bart.
