Bug 1430822 - pvscan/vgscan/lvscan/lvmdiskscan need to call function "lvmnotify_send" too
Summary: pvscan/vgscan/lvscan/lvmdiskscan need to call function "lvmnotify_send" too
Keywords:
Status: NEW
Alias: None
Product: LVM and device-mapper
Classification: Community
Component: lvm2
Version: 2.02.167
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
: ---
Assignee: LVM Team
QA Contact: cluster-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-09 16:14 UTC by Tony Asleson
Modified: 2023-08-10 15:40 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:
rule-engine: lvm-technical-solution?
rule-engine: lvm-test-coverage?


Attachments (Terms of Use)

Description Tony Asleson 2017-03-09 16:14:31 UTC
Description of problem:

If a user runs any of the scan command line tools the lvm dbus service does not get an event which tells it to update it's state.

Additionally if a user does a `wipefs -a /dev/sdc` on a PV or a disk that contains a PV(s) simply disappears, the lvm dbus service needs to be aware of this event too.  Perhaps a udev rule that runs pvscan which in turn would generate an event to the lvm dbus service?  

Note: The dbus service disables udev monitoring when lvm delivers an event to the lvm dbus service via the function lvmnotify_send.


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

LVM version:     2.02.167(2) (2016-11-05)
Library version: 1.02.136 (2016-11-05)
Driver version:  4.35.0


How reproducible:
100%


Steps to Reproduce:
1.Run the lvm dbus service with --debug
2.Create something from the command line, eg. vgcreate
3.Note that the service gets a udev event and a lvm event and disables udev
4.wipefs -a <some pv>, note that the lvm dbus service is unaware
5.run pvscan --cache from command line and see that the lvm service is still unaware

Actual results:
lvm dbus service does not know of state change


Expected results:
lvm dbus service is notified of state change


Additional info:

Comment 1 David Teigland 2017-03-09 16:39:26 UTC
First to clarify how this is part of a broader issue...  Both lvmetad and lvmdbusd cache information about device state and lvm state.  If device/lvm state is modified through lvm tools, then lvm can update the state in lvmetad/lvmdbusd.  But, if device/lvm state is modified by non-lvm tools, then lvmetad/lvmdbusd are not updated.

To work around this problem, the command 'pvscan --cache' exists so a person can manually refresh all the lvmetad state.  lvmdbusd needs the same kind of thing, so a user can manually refresh all the lvmdbusd state.  Is the command 'vgscan --notifydbus' sufficent for this, or do we need something more?

Comment 2 Tony Asleson 2017-03-09 16:54:19 UTC
(In reply to David Teigland from comment #1)
> First to clarify how this is part of a broader issue...  Both lvmetad and
> lvmdbusd cache information about device state and lvm state.  If device/lvm
> state is modified through lvm tools, then lvm can update the state in
> lvmetad/lvmdbusd.  But, if device/lvm state is modified by non-lvm tools,
> then lvmetad/lvmdbusd are not updated.
> 
> To work around this problem, the command 'pvscan --cache' exists so a person
> can manually refresh all the lvmetad state.  lvmdbusd needs the same kind of
> thing, so a user can manually refresh all the lvmdbusd state.  Is the
> command 'vgscan --notifydbus' sufficent for this, or do we need something
> more?

I would like to see all the "scan" tools simply kick the lvm dbus service to ensure it's up to date.  My preference would be for the user to not have to explicitly pass something on the lvm command line to do this as it's really an implementation detail IMHO.

Comment 3 David Teigland 2017-03-09 17:21:57 UTC
Sounds reasonable to make the 'scan --cache' commands automatically generate a dbus signal.  Trivial patch; I'll do this after 7.4 changes are done.


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