Bug 817854 - dm events: find a more-efficient event mechanism than DM_DEV_WAIT when many devices
dm events: find a more-efficient event mechanism than DM_DEV_WAIT when many d...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Alasdair Kergon
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks: 814855 stratis-lvm-reqs 1475380
  Show dependency treegraph
 
Reported: 2012-05-01 11:21 EDT by Alasdair Kergon
Modified: 2017-07-26 10:22 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1475380 (view as bug list)
Environment:
Last Closed: 2017-07-26 10:20:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alasdair Kergon 2012-05-01 11:21:52 EDT
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?)
Comment 2 RHEL Product and Program Management 2012-05-05 00:14:27 EDT
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.
Comment 4 Andy Grover 2015-11-10 03:03:50 EST
(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.
Comment 6 Andy Grover 2016-01-06 18:23:13 EST
Actually it appears DM events are also exported via uevents. Should dmeventd just use that?
Comment 7 Andy Grover 2016-01-06 19:13:31 EST
Doh, looks like there'd be some work to hook up uevents other than multipath.
Comment 8 Ben Marzinski 2016-01-07 16:31:17 EST
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.
Comment 9 Jonathan Earl Brassow 2017-07-26 10:20:12 EDT
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

Note You need to log in before you can comment on or make changes to this bug.