dmeventd needs to wait on many devices concurrently. Currently one ioctl is needed per device - either 1 thread per device, or polling all devices separately at intervals. Find something more efficient. (Separate netlink events? Grouping?)
Since RHEL 6.3 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
(In reply to Alasdair Kergon from comment #0) > Find something more efficient. > (Separate netlink events? Grouping?) Yes generic netlink (genl) could be a good approach. This would give user processes a single pollable fd for all events, and would allow multiple listeners.
Actually it appears DM events are also exported via uevents. Should dmeventd just use that?
Doh, looks like there'd be some work to hook up uevents other than multipath.
There is one thing to think about. dm-events are guaranteed to not get lost. Netlink events/uevent are just best-effort. Now I doubt there would be many missed events, if a userspace process waited directly on the netlink events, and read them promptly, but it is worth considering. I've often pondered the idea of scrapping the multipath waiter threads, and just using netlink events. But if I did that, multipathd would verify that it's view of the device was up to date every so often in the checker loop, along with checking paths. I think, just to be safe, anything that got its updates via netlink events would want to do something similiar. The idea of being able to wait for dm_events from a group of devices via a single call sounds nice though.
This request has been completed upstream: 23d70c5 dm ioctl: report event number in DM_LIST_DEVICES fc1841e dm ioctl: add a new DM_DEV_ARM_POLL ioctl 93e6442 dm: add basic support for using the select or poll function # git tag --contains 23d70c5 v4.13-rc1 v4.13-rc2