Bug 2165159 - handle filters with device symlinks during autoactivation
Summary: handle filters with device symlinks during autoactivation
Keywords:
Status: VERIFIED
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: lvm2
Version: 9.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: David Teigland
QA Contact: cluster-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-01-27 23:34 UTC by David Teigland
Modified: 2023-08-10 15:40 UTC (History)
8 users (show)

Fixed In Version: lvm2-2.03.21-1.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker CLUSTERQE-6687 0 None None None 2023-05-16 00:14:57 UTC
Red Hat Issue Tracker RHELPLAN-146788 0 None None None 2023-01-27 23:37:03 UTC

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.


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