Bug 2165159

Summary:	handle filters with device symlinks during autoactivation
Product:	Red Hat Enterprise Linux 9	Reporter:	David Teigland <teigland>
Component:	lvm2	Assignee:	David Teigland <teigland>
lvm2 sub component:	Activating existing Logical Volumes	QA Contact:	cluster-qe <cluster-qe>
Status:	VERIFIED ---	Docs Contact:
Severity:	unspecified
Priority:	unspecified	CC:	agk, cmarthal, heinzm, jbrassow, mcsontos, msnitzer, prajnoha, zkabelac
Version:	9.2	Keywords:	Triaged
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	lvm2-2.03.21-1.el9	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:

Description David Teigland 2023-01-27 23:34:00 UTC

Description of problem:

Reported in https://github.com/lvmteam/lvm2/issues/104

If the lvm.conf filter identifies devices using symlinks, then autoactivation may fail for those devices.

This requires that the devices file has been disabled, and the lvm.conf filter is used instead.

The new RHEL9 udev rule calls pvscan and vgchange using the kernel device name (e.g. /dev/sda.)  This device name will not match symlink names in the lvm.conf filter, so the devices will be ignored and autoactivation won't happen for them.

A previous solution to this problem had pvscan look in /dev for symlinks for the kernel device.  This was not reliable because the symlinks would not always be created in time to be seen by pvscan (they are being created by other udev rules.)

Now pvscan uses the DEVLINKS env var, set by udev, to get a list of all symlink names for the device, and uses those names to evaluate the filter reliably.  vgchange --autoactivation event uses only devices that have been processed by pvscan, so it inherits the filtering from pvscan and can skip the regex filtering itself.


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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 David Teigland 2023-01-31 21:50:14 UTC

fixed in main
https://sourceware.org/git/?p=lvm2.git;a=commit;h=17a3585cbb55d9a15ced9775a18b50c53a50ee8e
https://sourceware.org/git/?p=lvm2.git;a=commit;h=c9fdc828ff0504bc2e57f65862bc382f7663a8a2
https://sourceware.org/git/?p=lvm2.git;a=commit;h=6d14144d311fb347e4225ad6a48d4900b39445c4

Testing this involves rebooting the system and verifying that things are properly activated and mounted.  Set a filter for two PVs using symlinks for those PVs, e.g. wwn- or pci- or lvm-pv-uuid- symlinks in /dev/disk/by-id or /dev/disk/by-path.  One disk is for the root VG, and the second disk for an extra VG.  The extra VG contains an LV with a file system, where the fs is listed in /etc/fstab.  Reboot the machine and verify that it starts correctly, and that the LV in the extra VG is mounted.

The following is reported both before and after rebooting:

$ grep 'filter=' /etc/lvm/lvm.conf
        filter=[ "a|/dev/disk/by-path/pci-0000:04:00.0-part2|", "a|/dev/disk/by-path/pci-0000:07:00.0-scsi-0:0:0:17409|", "r|.*|" ]

$ vgs
  VG   #PV #LV #SN Attr   VSize    VFree  
  rhel   1   2   0 wz--n-  <49.00g      0 
  test   1   1   0 wz--n- 1020.00m 788.00m
$ pvs
  PV         VG   Fmt  Attr PSize    PFree  
  /dev/sda   test lvm2 a--  1020.00m 788.00m
  /dev/vda2  rhel lvm2 a--   <49.00g      0 
$ lvs
  LV   VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root rhel -wi-ao---- <45.05g                                                    
  swap rhel -wi-ao----  <3.95g                                                    
  foo  test -wi-ao---- 232.00m                                                    
$ df
Filesystem            1K-blocks    Used Available Use% Mounted on
/dev/mapper/rhel-root  47212008 4233440  42978568   9% /
/dev/mapper/test-foo     232096   13760    218336   6% /foo


Note that this test may not fail if it's run without the patches, but depending on timing it may fail unpredictably without the patches.

Comment 4 Corey Marthaler 2023-06-20 16:00:54 UTC

Marking Verified:Tested (and SanityOnly due to the timing requirements) based on the results of comment #1.