Bug 1384899

Summary:	[RFE] Redesign dmeventd to better utilize new lvmpolld mechanism
Product:	[Community] LVM and device-mapper	Reporter:	Zdenek Kabelac <zkabelac>
Component:	lvm2	Assignee:	XiaoNi <xni>
lvm2 sub component:	dmeventd	QA Contact:	cluster-qe <cluster-qe>
Status:	NEW ---	Docs Contact:
Severity:	unspecified
Priority:	medium	CC:	agk, heinzm, jbrassow, msnitzer, prajnoha, thornber, zkabelac
Version:	2.02.166	Flags:	rule-engine: lvm-technical-solution? rule-engine: lvm-test-coverage?
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2044232

Description Zdenek Kabelac 2016-10-14 10:50:40 UTC

Description of problem:

Existing dmeventd logic uses a single lvm2 thread to process all repair commands. Idea here is the usually disasters do not happen all at the same time. However 'standalone' mirror repair may takes hours to replicate mirror image and during this time dmeventd is not able to do any other action.

Now we have lvmpolld to offload most of its work to external process and making dmeventd responsible only for quick urgent repair again and leaving long running task again being executed bug 'normal' daemons (without memlocking issues like dmeventd is using).

This should also lead to better command repair split - where only 'urgent-repair' parts are running within command context - and later i.e. mirror leg addition and resynchronization are fully under lvmpolld control.

It's important dmeventd quickly returns back to monitoring and is able to handle other incoming events.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Jonathan Earl Brassow 2019-10-23 20:45:34 UTC

see also bug 814855