* [linux-lvm] confused with lvm2 filter rules @ 2019-06-03 13:03 Heming Zhao 2019-06-05 2:41 ` Heming Zhao 2019-06-05 10:20 ` Zdenek Kabelac 0 siblings, 2 replies; 13+ messages in thread From: Heming Zhao @ 2019-06-03 13:03 UTC (permalink / raw) To: linux-lvm Hello, I met below filter action when executed 'vgextend'. why the filter take no effect on executing pvcreate or vgcreate? ``` # ls -l /dev/disk/by-id/scsi-* lrwxrwxrwx 1 root root 9 Jun 3 20:44 /dev/disk/by-id/scsi-360073a707 -> ../../sda lrwxrwxrwx 1 root root 9 Jun 3 20:44 /dev/disk/by-id/scsi-36007c0036 -> ../../sdb lrwxrwxrwx 1 root root 9 Jun 3 20:27 /dev/disk/by-id/scsi-3600b99ec4 -> ../../sdc # pvcreate /dev/disk/by-id/scsi-36073a707 /dev/disk/by-id/scsi-36007c0036 # pvs PV VG Fmt Attr PSize PFree /dev/sda lvm2 --- 2.00g 2.00g /dev/sdb lvm2 --- 2.00g 2.00g # vgcreate vgtst /dev/disk/by-id/scsi-36073a707 /dev/disk/by-id/scsi-36007c0036hy the filter take no effect on executing pvcreate or vgcreate? # vgs VG #PV #LV #SN Attr VSize VFree vgtst 2 0 0 wz--n- 3.98g 3.98g # vgextend vgtst /dev/disk/by-id/scsi-3600b99ec4 Device /dev/disk/by-id/scsi-3600b99ec4 excluded by a filter. # vgs VG #PV #LV #SN Attr VSize VFree vgtst 2 0 0 wz--n- 3.98g 3.98g my enviroment: # rpm -qa | grep lvm2 lvm2-clvm-2.02.180-8.16.x86_64 lvm2-cmirrord-2.02.180-8.16.x86_64 lvm2-2.02.180-8.16.x86_64 the filter rules: (you can see all the disk in /dev/disk/by-id/ are rejected) # grep filter /etc/lvm/lvm.conf | grep -v "#" filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", "r|/dev/fd.*|", "r|/dev/cdrom|", "a/.*/" ] ``` Thank you. zhm ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [linux-lvm] confused with lvm2 filter rules 2019-06-03 13:03 [linux-lvm] confused with lvm2 filter rules Heming Zhao @ 2019-06-05 2:41 ` Heming Zhao 2019-06-05 10:20 ` Zdenek Kabelac 1 sibling, 0 replies; 13+ messages in thread From: Heming Zhao @ 2019-06-05 2:41 UTC (permalink / raw) To: linux-lvm Hello list, Can anybody help me for this question? I tried on suse & centos with lvm2-2.02.180, both system have this issue. The filter in /etc/lvm/lvm.conf only works with vgextend command. It take no effect on pvcreate, vgcreate & vgreduce. Thank you. On 6/3/19 9:03 PM, Heming Zhao wrote: > Hello, > > I met below filter action when executed 'vgextend'. > why the filter take no effect on executing pvcreate or vgcreate? > > ``` > # ls -l /dev/disk/by-id/scsi-* > lrwxrwxrwx 1 root root 9 Jun 3 20:44 /dev/disk/by-id/scsi-360073a707 -> > ../../sda > lrwxrwxrwx 1 root root 9 Jun 3 20:44 /dev/disk/by-id/scsi-36007c0036 -> > ../../sdb > lrwxrwxrwx 1 root root 9 Jun 3 20:27 /dev/disk/by-id/scsi-3600b99ec4 -> > ../../sdc > # pvcreate /dev/disk/by-id/scsi-36073a707 /dev/disk/by-id/scsi-36007c0036 > # pvs > PV VG Fmt Attr PSize PFree > /dev/sda lvm2 --- 2.00g 2.00g > /dev/sdb lvm2 --- 2.00g 2.00g > # vgcreate vgtst /dev/disk/by-id/scsi-36073a707 > /dev/disk/by-id/scsi-36007c0036hy the filter take no effect on executing > pvcreate or vgcreate? > # vgs > VG #PV #LV #SN Attr VSize VFree > vgtst 2 0 0 wz--n- 3.98g 3.98g > # vgextend vgtst /dev/disk/by-id/scsi-3600b99ec4 > Device /dev/disk/by-id/scsi-3600b99ec4 excluded by a filter. > # vgs > VG #PV #LV #SN Attr VSize VFree > vgtst 2 0 0 wz--n- 3.98g 3.98g > > my enviroment: > # rpm -qa | grep lvm2 > lvm2-clvm-2.02.180-8.16.x86_64 > lvm2-cmirrord-2.02.180-8.16.x86_64 > lvm2-2.02.180-8.16.x86_64 > > the filter rules: (you can see all the disk in /dev/disk/by-id/ are > rejected) > # grep filter /etc/lvm/lvm.conf | grep -v "#" > filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", > "r|/dev/fd.*|", "r|/dev/cdrom|", "a/.*/" ] > ``` > > > Thank you. > zhm > > _______________________________________________ > linux-lvm mailing list > linux-lvm@redhat.com > https://www.redhat.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [linux-lvm] confused with lvm2 filter rules 2019-06-03 13:03 [linux-lvm] confused with lvm2 filter rules Heming Zhao 2019-06-05 2:41 ` Heming Zhao @ 2019-06-05 10:20 ` Zdenek Kabelac 2019-06-06 6:42 ` Heming Zhao 2019-06-06 8:16 ` Heming Zhao 1 sibling, 2 replies; 13+ messages in thread From: Zdenek Kabelac @ 2019-06-05 10:20 UTC (permalink / raw) To: LVM general discussion and development, Heming Zhao Dne 03. 06. 19 v 15:03 Heming Zhao napsal(a): > Hello, > > I met below filter action when executed 'vgextend'. > why the filter take no effect on executing pvcreate or vgcreate? > # rpm -qa | grep lvm2 > lvm2-clvm-2.02.180-8.16.x86_64 > lvm2-cmirrord-2.02.180-8.16.x86_64 > lvm2-2.02.180-8.16.x86_64 > > the filter rules: (you can see all the disk in /dev/disk/by-id/ are > rejected) > # grep filter /etc/lvm/lvm.conf | grep -v "#" > filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", > "r|/dev/fd.*|", "r|/dev/cdrom|", "a/.*/" ] Hi Filter with 'a|.*|' at the end will almost always never work. As devices do have several names so if you reject it by one name, you will likely accept it with another name. So I'd highly recommend only these 2 variants that are 'easy to follow'. 1. White-list devices you want to see and add r|.*| as the last rule. ^^^^^^^^^^^^^^^ most recommended. 2. Pure list of reject rules (do not add any 'a' rule). Regards Zdenek ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [linux-lvm] confused with lvm2 filter rules 2019-06-05 10:20 ` Zdenek Kabelac @ 2019-06-06 6:42 ` Heming Zhao 2019-06-06 8:16 ` Heming Zhao 1 sibling, 0 replies; 13+ messages in thread From: Heming Zhao @ 2019-06-06 6:42 UTC (permalink / raw) To: Zdenek Kabelac, LVM general discussion and development Hello Zdenek, Thank you very much for your explanation. Regards, zhm On 6/5/19 6:20 PM, Zdenek Kabelac wrote: > Dne 03. 06. 19 v 15:03 Heming Zhao napsal(a): >> Hello, >> >> I met below filter action when executed 'vgextend'. >> why the filter take no effect on executing pvcreate or vgcreate? > >> # rpm -qa | grep lvm2 >> lvm2-clvm-2.02.180-8.16.x86_64 >> lvm2-cmirrord-2.02.180-8.16.x86_64 >> lvm2-2.02.180-8.16.x86_64 >> >> the filter rules:� (you can see all the disk in /dev/disk/by-id/ are >> rejected) >> # grep filter /etc/lvm/lvm.conf | grep -v "#" >> ����� filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", >> "r|/dev/fd.*|", "r|/dev/cdrom|", "a/.*/" ] > > > Hi > > Filter with 'a|.*|' at the end will almost always never work. > As devices do have several names so if you reject it by one name, > you will likely accept it with another name. > > > So I'd highly recommend only these 2 variants that are 'easy to follow'. > > > 1. White-list devices you want to see and add r|.*|� as the last rule. > ^^^^^^^^^^^^^^^ most recommended. > > 2. Pure list of reject rules (do not add any 'a' rule). > > Regards > > Zdenek > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [linux-lvm] confused with lvm2 filter rules 2019-06-05 10:20 ` Zdenek Kabelac 2019-06-06 6:42 ` Heming Zhao @ 2019-06-06 8:16 ` Heming Zhao 2019-06-06 8:43 ` Zdenek Kabelac 1 sibling, 1 reply; 13+ messages in thread From: Heming Zhao @ 2019-06-06 8:16 UTC (permalink / raw) To: Zdenek Kabelac, LVM general discussion and development Hello, BTW, Only vgextend doesn't work, which must be a bug. It looks the filter handling codes have bug. Regards, zhm On 6/5/19 6:20 PM, Zdenek Kabelac wrote: > Dne 03. 06. 19 v 15:03 Heming Zhao napsal(a): >> Hello, >> >> I met below filter action when executed 'vgextend'. >> why the filter take no effect on executing pvcreate or vgcreate? > >> # rpm -qa | grep lvm2 >> lvm2-clvm-2.02.180-8.16.x86_64 >> lvm2-cmirrord-2.02.180-8.16.x86_64 >> lvm2-2.02.180-8.16.x86_64 >> >> the filter rules:� (you can see all the disk in /dev/disk/by-id/ are >> rejected) >> # grep filter /etc/lvm/lvm.conf | grep -v "#" >> ����� filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", >> "r|/dev/fd.*|", "r|/dev/cdrom|", "a/.*/" ] > > > Hi > > Filter with 'a|.*|' at the end will almost always never work. > As devices do have several names so if you reject it by one name, > you will likely accept it with another name. > > > So I'd highly recommend only these 2 variants that are 'easy to follow'. > > > 1. White-list devices you want to see and add r|.*|� as the last rule. > ^^^^^^^^^^^^^^^ most recommended. > > 2. Pure list of reject rules (do not add any 'a' rule). > > Regards > > Zdenek > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [linux-lvm] confused with lvm2 filter rules 2019-06-06 8:16 ` Heming Zhao @ 2019-06-06 8:43 ` Zdenek Kabelac 2019-06-06 13:30 ` Heming Zhao 0 siblings, 1 reply; 13+ messages in thread From: Zdenek Kabelac @ 2019-06-06 8:43 UTC (permalink / raw) To: LVM general discussion and development, Heming Zhao, Zdenek Kabelac Dne 06. 06. 19 v 10:16 Heming Zhao napsal(a): > Hello, > > BTW, > Only vgextend doesn't work, which must be a bug. It looks the filter > handling codes have bug. > Hi Please provide full 'vgextend -vvvv' trace with some explanation of what you believe is a bug in handling code. Regards Zdenek ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [linux-lvm] confused with lvm2 filter rules 2019-06-06 8:43 ` Zdenek Kabelac @ 2019-06-06 13:30 ` Heming Zhao 2019-06-06 13:51 ` Zdenek Kabelac 0 siblings, 1 reply; 13+ messages in thread From: Heming Zhao @ 2019-06-06 13:30 UTC (permalink / raw) To: Zdenek Kabelac, LVM general discussion and development Hello, the filter is: filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", "r|/dev/fd.*|", "r|/dev/cdrom|", "a/.*/" ] if filter doesn't contain "a/.*/": - pvcreate, vgcreate & vgextend use regex filter to reject the disk. (correct logic) if filter contains "a/.*/": - regex fileter pass the disk under pvcreate/vgcreate, create successfully. - regex filter reject the disk under vgextend. (wrong. should create successfuly) - vgextend should do the same action as pvcreate/vgcreate. log as below (with filter contain: "a/.*/"): ------------------------ # vgextend -vvvv vgtst /dev/disk/by-id/scsi-360014051ec87260bf98462eb448 0b3b3 #lvmcmdline.c:2814 Parsing: vgextend -vvvv vgtst /dev/disk/by-id/scsi-360014051ec87260bf98462eb4480b3b3 #lvmcmdline.c:1868 Recognised command vgextend_general (id 128 / enum 113). #config/config.c:1480 devices/global_filter not found in config: defaulting to global_filter = [ "a|.*/|" ] #libdm-config.c:1002 global/lvmetad_update_wait_time not found in config: defaulting to 10 #daemon-client.c:33 /run/lvm/lvmetad.socket: Opening daemon socket to lvmetad for protocol lvmetad version 1. #daemon-client.c:52 Sending daemon lvmetad: hello #cache/lvmetad.c:141 Successfully connected to lvmetad on fd 3. #libdm-config.c:1074 global/use_lvmpolld not found in config: defaulting to 1 #filters/filter-sysfs.c:327 Sysfs filter initialised. #filters/filter-internal.c:77 Internal filter initialised. #filters/filter-type.c:56 LVM type filter initialised. #filters/filter-usable.c:183 Usable device filter initialised. #filters/filter-mpath.c:291 mpath filter initialised. #filters/filter-partitioned.c:69 Partitioned filter initialised. #filters/filter-signature.c:84 signature filter initialised. #filters/filter-md.c:169 MD filter initialised. #libdm-config.c:1074 devices/fw_raid_component_detection not found in config: defaulting to 0 #filters/filter-composite.c:109 Composite filter initialised. #config/config.c:1483 Setting devices/filter to filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", "r|/dev/fd.*|", "r|/dev/cdrom|", "a/.*/" ] #filters/filter-regex.c:216 Regex filter initialised. #filters/filter-usable.c:183 Usable device filter initialised. #filters/filter-composite.c:109 Composite filter initialised. #libdm-config.c:975 devices/cache not found in config: defaulting to /etc/lvm/cache/.cache #filters/filter-persistent.c:415 Persistent filter initialised. #filters/filter-composite.c:109 Composite filter initialised. #libdm-config.c:1074 metadata/record_lvs_history not found in config: defaulting to 0 #lvmcmdline.c:2882 DEGRADED MODE. Incomplete RAID LVs will be processed. #lvmcmdline.c:2888 Processing command: vgextend -vvvv vgtst /dev/disk/by-id/scsi-360014051ec87260bf98462eb4480b3b3 #lvmcmdline.c:2889 Command pid: 17557 #lvmcmdline.c:2890 System ID: #lvmcmdline.c:2893 O_DIRECT will be used #locking/locking.c:129 File-based locking selected. #libdm-config.c:1074 global/use_lvmlockd not found in config: defaulting to 0 #cache/lvmetad.c:254 Sending lvmetad get_global_info #libdm-config.c:1074 metadata/pvmetadataignore not found in config: defaulting to 0 #libdm-config.c:1002 metadata/pvmetadatasize not found in config: defaulting to 255 #libdm-config.c:1002 metadata/pvmetadatacopies not found in config: defaulting to 1 #libdm-config.c:975 report/output_format not found in config: defaulting to basic #libdm-config.c:1074 log/report_command_log not found in config: defaulting to 0 #cache/lvmcache.c:2535 Dropping VG info #cache/lvmcache.c:751 lvmcache has no info for vgname "#orphans_lvm2" with VGID #orphans_lvm2. #cache/lvmcache.c:751 lvmcache has no info for vgname "#orphans_lvm2". #cache/lvmcache.c:2082 lvmcache: Initialised VG #orphans_lvm2. #locking/locking.c:331 Dropping cache for #orphans. #misc/lvm-flock.c:202 Locking /run/lvm/lock/P_orphans WB #misc/lvm-flock.c:100 _do_flock /run/lvm/lock/P_orphans:aux WB #misc/lvm-flock.c:100 _do_flock /run/lvm/lock/P_orphans WB #misc/lvm-flock.c:47 _undo_flock /run/lvm/lock/P_orphans:aux #cache/lvmcache.c:751 lvmcache has no info for vgname "#orphans". #device/dev-cache.c:723 Found dev 8:32 /dev/disk/by-id/scsi-360014051ec87260bf98462eb4480b3b3 - new. #device/dev-io.c:609 Opened /dev/disk/by-id/scsi-360014051ec87260bf98462eb4480b3b3 RO O_DIRECT #device/dev-io.c:359 /dev/disk/by-id/scsi-360014051ec87260bf98462eb4480b3b3: size is 1024000 sectors #device/dev-io.c:658 Closed /dev/disk/by-id/scsi-360014051ec87260bf98462eb4480b3b3 #device/dev-io.c:336 /dev/disk/by-id/scsi-360014051ec87260bf98462eb4480b3b3: using cached size 1024000 sectors #filters/filter-regex.c:172 /dev/disk/by-id/scsi-360014051ec87260bf98462eb4480b3b3: Skipping (regex) #filters/filter-persistent.c:346 filter caching bad /dev/disk/by-id/scsi-360014051ec87260bf98462eb4480b3b3 #toollib.c:4451 Processing each PV #cache/lvmetad.c:1445 Asking lvmetad for complete list of known VG ids/names #toollib.c:3941 Getting list of all devices #device/dev-cache.c:1212 Creating list of system devices. #device/dev-cache.c:723 Found dev 253:0 /dev/vda - new. #device/dev-cache.c:723 Found dev 253:1 /dev/vda1 - new. #device/dev-cache.c:763 Found dev 253:1 /dev/disk/by-partuuid/000c10c1-01 - new alias. #device/dev-cache.c:763 Found dev 253:1 /dev/disk/by-uuid/060ece02-7ac0-49bd-88cf-2853fe388671 - new alias. #device/dev-cache.c:723 Found dev 253:2 /dev/vda2 - new. #device/dev-cache.c:763 Found dev 253:2 /dev/disk/by-partuuid/000c10c1-02 - new alias. #device/dev-cache.c:763 Found dev 253:2 /dev/disk/by-uuid/f545996e-247f-4778-ab81-7c7b6140d23a - new alias. #device/dev-cache.c:763 Found dev 253:2 /dev/root - new alias. #device/dev-cache.c:723 Found dev 8:0 /dev/sda - new. #device/dev-cache.c:763 Found dev 8:0 /dev/disk/by-id/lvm-pv-uuid-2n9LLa-sWow-ZYA3-jiRX-5yfc-ghcq-119083 - new alias. #device/dev-cache.c:763 Found dev 8:0 /dev/disk/by-id/scsi-1LIO-ORG_FILEIO:78c8c971-44e0-4791-aa89-97ad40cb48d1 - new alias. #device/dev-cache.c:763 Found dev 8:0 /dev/disk/by-id/scsi-3600140578c8c97144e04791aa8997ad4 - new alias. #device/dev-cache.c:763 Found dev 8:0 /dev/disk/by-id/scsi-SLIO-ORG_FILEIO_78c8c971-44e0-4791-aa89-97ad40cb48d1 - new alias. #device/dev-cache.c:763 Found dev 8:0 /dev/disk/by-id/wwn-0x600140578c8c97144e04791aa8997ad4 - new alias. #device/dev-cache.c:763 Found dev 8:0 /dev/disk/by-path/ip-10.67.17.201:3260-iscsi-iqn.2019-06.com.example:iscsi-500m-disk01-lun-0 - new alias. #device/dev-cache.c:723 Found dev 8:16 /dev/sdb - new. #device/dev-cache.c:763 Found dev 8:16 /dev/disk/by-id/lvm-pv-uuid-FQqmv2-8mTk-5r4r-cwvn-8HJ1-GDBH-svklEf - new alias. #device/dev-cache.c:763 Found dev 8:16 /dev/disk/by-id/scsi-1LIO-ORG_FILEIO:a7ec3a1e-70d4-4a47-b16d-2e404f27b30c - new alias. #device/dev-cache.c:763 Found dev 8:16 /dev/disk/by-id/scsi-36001405a7ec3a1e70d44a47b16d2e404 - new alias. #device/dev-cache.c:763 Found dev 8:16 /dev/disk/by-id/scsi-SLIO-ORG_FILEIO_a7ec3a1e-70d4-4a47-b16d-2e404f27b30c - new alias. #device/dev-cache.c:763 Found dev 8:16 /dev/disk/by-id/wwn-0x6001405a7ec3a1e70d44a47b16d2e404 - new alias. #device/dev-cache.c:763 Found dev 8:16 /dev/disk/by-path/ip-10.67.17.201:3260-iscsi-iqn.2019-06.com.example:iscsi-500m-disk02-lun-0 - new alias. #device/dev-cache.c:763 Found dev 8:32 /dev/sdc - new alias. #device/dev-cache.c:763 Found dev 8:32 /dev/disk/by-id/scsi-1LIO-ORG_FILEIO:1ec87260-bf98-462e-b448-0b3b32f1e1c4 - new alias. #device/dev-cache.c:714 Found dev 8:32 /dev/disk/by-id/scsi-360014051ec87260bf98462eb4480b3b3 - exists. #device/dev-cache.c:763 Found dev 8:32 /dev/disk/by-id/scsi-SLIO-ORG_FILEIO_1ec87260-bf98-462e-b448-0b3b32f1e1c4 - new alias. #device/dev-cache.c:763 Found dev 8:32 /dev/disk/by-id/wwn-0x60014051ec87260bf98462eb4480b3b3 - new alias. #device/dev-cache.c:763 Found dev 8:32 /dev/disk/by-path/ip-10.67.17.201:3260-iscsi-iqn.2019-06.com.example:iscsi-500m-disk03-lun-0 - new alias. #cache/lvmetad.c:1420 Asking lvmetad for complete list of known PVs #filters/filter-persistent.c:346 filter caching good /dev/sdb #cache/lvmcache.c:751 lvmcache has no info for vgname "vgtst" with VGID PFEUFqY9UO1SFYoNiIgPEk90ThVmDDx0. #cache/lvmcache.c:751 lvmcache has no info for vgname "vgtst". #cache/lvmcache.c:2080 lvmcache /dev/sdb: now in VG vgtst with 0 mda(s). #cache/lvmcache.c:1906 lvmcache /dev/sdb: VG vgtst: set VGID to PFEUFqY9UO1SFYoNiIgPEk90ThVmDDx0. #filters/filter-persistent.c:346 filter caching good /dev/sda #cache/lvmcache.c:2080 lvmcache /dev/sda: now in VG vgtst (PFEUFqY9UO1SFYoNiIgPEk90ThVmDDx0) with 0 mda(s). #device/dev-io.c:609 Opened /dev/sda RO O_DIRECT #device/dev-io.c:359 /dev/sda: size is 1024000 sectors #device/dev-io.c:658 Closed /dev/sda #device/dev-io.c:336 /dev/sda: using cached size 1024000 sectors #filters/filter-persistent.c:312 /dev/sda: filter cache using (cached good) #device/dev-io.c:609 Opened /dev/vda RO O_DIRECT #device/dev-io.c:359 /dev/vda: size is 83886080 sectors #device/dev-io.c:658 Closed /dev/vda #filters/filter-partitioned.c:37 /dev/vda: Skipping: Partition table signature found #device/dev-io.c:609 Opened /dev/vda1 RO O_DIRECT #device/dev-io.c:359 /dev/vda1: size is 3002368 sectors #device/dev-io.c:658 Closed /dev/vda1 #device/dev-io.c:336 /dev/vda1: using cached size 3002368 sectors #filters/filter-persistent.c:346 filter caching good /dev/vda1 #device/dev-io.c:609 Opened /dev/root RO O_DIRECT #device/dev-io.c:359 /dev/root: size is 80881664 sectors #device/dev-io.c:658 Closed /dev/root #device/dev-io.c:336 /dev/root: using cached size 80881664 sectors #filters/filter-persistent.c:346 filter caching good /dev/root #device/dev-io.c:609 Opened /dev/sdb RO O_DIRECT #device/dev-io.c:359 /dev/sdb: size is 1024000 sectors #device/dev-io.c:658 Closed /dev/sdb #device/dev-io.c:336 /dev/sdb: using cached size 1024000 sectors #filters/filter-persistent.c:312 /dev/sdb: filter cache using (cached good) #device/dev-io.c:336 /dev/sdc: using cached size 1024000 sectors #device/dev-io.c:336 /dev/sdc: using cached size 1024000 sectors #filters/filter-persistent.c:346 filter caching good /dev/sdc #toollib.c:4377 Processing PVs in VG vgtst #locking/locking.c:331 Dropping cache for vgtst. #misc/lvm-flock.c:202 Locking /run/lvm/lock/V_vgtst RB #misc/lvm-flock.c:100 _do_flock /run/lvm/lock/V_vgtst:aux WB #misc/lvm-flock.c:47 _undo_flock /run/lvm/lock/V_vgtst:aux #misc/lvm-flock.c:100 _do_flock /run/lvm/lock/V_vgtst RB #metadata/metadata.c:3778 Reading VG vgtst PFEUFq-Y9UO-1SFY-oNiI-gPEk-90Th-VmDDx0 #cache/lvmetad.c:983 Asking lvmetad for VG PFEUFq-Y9UO-1SFY-oNiI-gPEk-90Th-VmDDx0 vgtst #filters/filter-persistent.c:312 /dev/sdb: filter cache using (cached good) #cache/lvmcache.c:2080 lvmcache /dev/sdb: now in VG #orphans_lvm2 (#orphans_lvm2) with 1 mda(s). #filters/filter-persistent.c:312 /dev/sda: filter cache using (cached good) #cache/lvmcache.c:2080 lvmcache /dev/sda: now in VG #orphans_lvm2 (#orphans_lvm2) with 1 mda(s). #metadata/vg.c:68 Allocated VG vgtst at 0x55c563bc5980. #cache/lvmcache.c:751 lvmcache has no info for vgname "vgtst" with VGID PFEUFqY9UO1SFYoNiIgPEk90ThVmDDx0. #cache/lvmcache.c:751 lvmcache has no info for vgname "vgtst". #cache/lvmcache.c:2080 lvmcache /dev/sdb: now in VG vgtst with 1 mda(s). #cache/lvmcache.c:1906 lvmcache /dev/sdb: VG vgtst: set VGID to PFEUFqY9UO1SFYoNiIgPEk90ThVmDDx0. #cache/lvmcache.c:2080 lvmcache /dev/sda: now in VG vgtst (PFEUFqY9UO1SFYoNiIgPEk90ThVmDDx0) with 1 mda(s). #cache/lvmetad.c:2462 Sending lvmetad vg_clear_outdated_pvs #device/dev-io.c:336 /dev/sdb: using cached size 1024000 sectors #device/dev-io.c:336 /dev/sda: using cached size 1024000 sectors #metadata/pv_manip.c:417 /dev/sdb 0: 0 123: NULL(0:0) #metadata/pv_manip.c:417 /dev/sda 0: 0 123: NULL(0:0) #metadata/vg.c:68 Allocated VG vgtst at 0x55c563bb2a90. #toollib.c:4269 Processing PV /dev/sdb in VG vgtst. #toollib.c:4269 Processing PV /dev/sda in VG vgtst. #mm/memlock.c:594 Unlock: Memlock counters: prioritized:0 locked:0 critical:0 daemon:0 suspended:0 #activate/fs.c:491 Syncing device names #locking/locking.c:331 Dropping cache for vgtst. #misc/lvm-flock.c:70 Unlocking /run/lvm/lock/V_vgtst #misc/lvm-flock.c:47 _undo_flock /run/lvm/lock/V_vgtst #metadata/vg.c:83 Freeing VG vgtst at 0x55c563bb2a90. #metadata/vg.c:83 Freeing VG vgtst at 0x55c563bc5980. #toollib.c:4377 Processing PVs in VG #orphans_lvm2 #metadata/metadata.c:5495 Locking #orphans_lvm2 already done #metadata/metadata.c:3764 Reading VG #orphans_lvm2 #locking/locking.c:331 Dropping cache for #orphans. #misc/lvm-flock.c:70 Unlocking /run/lvm/lock/P_orphans #misc/lvm-flock.c:47 _undo_flock /run/lvm/lock/P_orphans #cache/lvmcache.c:751 lvmcache has no info for vgname "#orphans". #locking/locking.c:331 Dropping cache for #orphans. #misc/lvm-flock.c:202 Locking /run/lvm/lock/P_orphans WB #misc/lvm-flock.c:100 _do_flock /run/lvm/lock/P_orphans:aux WB #misc/lvm-flock.c:100 _do_flock /run/lvm/lock/P_orphans WB #misc/lvm-flock.c:47 _undo_flock /run/lvm/lock/P_orphans:aux #cache/lvmcache.c:751 lvmcache has no info for vgname "#orphans". #metadata/metadata.c:3764 Reading VG #orphans_lvm2 #toollib.c:4056 Processing devices that are not PVs #toollib.c:4072 Processing device /dev/vda1. #toollib.c:4072 Processing device /dev/root. #toollib.c:4072 Processing device /dev/sdc. #toollib.c:5539 Device /dev/disk/by-id/scsi-360014051ec87260bf98462eb4480b3b3 excluded by a filter. #toollib.c:5545 <backtrace> #locking/locking.c:331 Dropping cache for #orphans. #misc/lvm-flock.c:70 Unlocking /run/lvm/lock/P_orphans #misc/lvm-flock.c:47 _undo_flock /run/lvm/lock/P_orphans #cache/lvmcache.c:751 lvmcache has no info for vgname "#orphans". #vgextend.c:177 <backtrace> #libdm-config.c:1074 global/notify_dbus not found in config: defaulting to 1 #cache/lvmcache.c:2535 Dropping VG info #cache/lvmcache.c:751 lvmcache has no info for vgname "#orphans_lvm2" with VGID #orphans_lvm2. #cache/lvmcache.c:751 lvmcache has no info for vgname "#orphans_lvm2". #cache/lvmcache.c:2082 lvmcache: Initialised VG #orphans_lvm2. #lvmcmdline.c:3028 Completed: vgextend -vvvv vgtst /dev/disk/by-id/scsi-360014051ec87260bf98462eb4480b3b3 On 6/6/19 4:43 PM, Zdenek Kabelac wrote: > Dne 06. 06. 19 v 10:16 Heming Zhao napsal(a): >> Hello, >> >> BTW, >> Only vgextend doesn't work, which must be a bug. It looks the filter >> handling codes have bug. >> > > Hi > > Please provide full 'vgextend -vvvv' trace� with some explanation of > what you believe is a bug in handling code. > > > Regards > > > Zdenek > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [linux-lvm] confused with lvm2 filter rules 2019-06-06 13:30 ` Heming Zhao @ 2019-06-06 13:51 ` Zdenek Kabelac 2019-06-10 2:43 ` Heming Zhao 0 siblings, 1 reply; 13+ messages in thread From: Zdenek Kabelac @ 2019-06-06 13:51 UTC (permalink / raw) To: Heming Zhao, LVM general discussion and development Dne 06. 06. 19 v 15:30 Heming Zhao napsal(a): > Hello, > > the filter is: > filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", > "r|/dev/fd.*|", "r|/dev/cdrom|", "a/.*/" ] > > if filter doesn't contain "a/.*/": > - pvcreate, vgcreate & vgextend use regex filter to reject the disk. > (correct logic) > > if filter contains "a/.*/": > - regex fileter pass the disk under pvcreate/vgcreate, create successfully. > - regex filter reject the disk under vgextend. (wrong. should create > successfuly) > - vgextend should do the same action as pvcreate/vgcreate. Hi As has been said - when you put a|.*| as the last rule - it's doing something different then you may think. So please do NOT test with such filter (I've been even planning to add 'WARNING:' message when lvm2 would spot such filter....) > log as below (with filter contain: "a/.*/"): Not really interesting trace - the filter works correctly for this case. The best advice is - DO NOT USE IT set this way. Code is correct and there is no bug - it's just non-trivial to understand what just filter is doing. Behavior cannot be changed without causing regression for other users that set filters correctly. So do you have any buggy trace for correctly set filter ? Regards Zdenek ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [linux-lvm] confused with lvm2 filter rules 2019-06-06 13:51 ` Zdenek Kabelac @ 2019-06-10 2:43 ` Heming Zhao [not found] ` <60982841-fabc-71d9-b8b1-6d98b87ba738@suse.com> 0 siblings, 1 reply; 13+ messages in thread From: Heming Zhao @ 2019-06-10 2:43 UTC (permalink / raw) To: Zdenek Kabelac, LVM general discussion and development Hello Zdenek, I totally got your point. Let's close this session. Thank you for you reply. Regards, zhm On 6/6/19 9:51 PM, Zdenek Kabelac wrote: > Dne 06. 06. 19 v 15:30 Heming Zhao napsal(a): >> Hello, >> >> the filter is: >> filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", >> "r|/dev/fd.*|", "r|/dev/cdrom|", "a/.*/" ] >> >> if filter doesn't contain "a/.*/": >> - pvcreate, vgcreate & vgextend use regex filter to reject the disk. >> (correct logic) >> �> if filter contains "a/.*/": >> - regex fileter pass the disk under pvcreate/vgcreate, create >> successfully. >> - regex filter reject the disk under vgextend. (wrong. should create >> successfuly) >> - vgextend should do the same action as pvcreate/vgcreate. > > Hi > > As has been said -�� when you put� a|.*| as the last rule - it's doing > something different then you may think. So please do NOT test with such > filter (I've been even planning to add 'WARNING:' message when lvm2 > would spot such filter....) > >> log as below (with filter contain: "a/.*/"): > > Not really interesting trace - the filter works correctly for this case. > > The best advice is - DO NOT USE IT set this way. > > Code is correct and there is no bug - it's just non-trivial to > understand what just filter is doing. Behavior cannot be changed without > causing regression for other users that set filters correctly. > > So do you have any buggy trace for correctly set filter ? > > Regards > > Zdenek > ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <60982841-fabc-71d9-b8b1-6d98b87ba738@suse.com>]
* Re: [linux-lvm] confused with lvm2 filter rules [not found] ` <60982841-fabc-71d9-b8b1-6d98b87ba738@suse.com> @ 2019-06-25 7:56 ` Martin Wilck 2019-06-25 8:56 ` Zdenek Kabelac 0 siblings, 1 reply; 13+ messages in thread From: Martin Wilck @ 2019-06-25 7:56 UTC (permalink / raw) To: LVM general discussion and development, Zdenek Kabelac, Heming Zhao Cc: Martin Wilck, David Teigland Hello Zdenek, On Tue, 2019-06-25 at 05:30 +0000, Heming Zhao wrote: > Hello Zdenek, > > I raise this topic again. Lvm should have bug in filter code. > Let me show the example. > > filter = [ "a|^/dev/sd.*|", "r|.*|" ] > As document description, above filter rules: > deny all the devices except "/dev/sd.*" > > issue: > pvcreate executes successfully with "/dev/disk/by-id/xxx", but > vgextend doesn't. > > expect result: > pvcreate should deny the device "/dev/disk/by-id/xxx". > I disagree with Heming in this point. IMO both pvcreate and vgextend should accept the device because of the first "a" rule. In any case, it's obviously wrong that the two tools behave differently. Note also that this difference occurs only if lvmetad is used. Without lvmetad, both commands accept the device. The reason is that in this case, lvmcache_label_scan(), which also builds the alias tree, is called before applying the filter. With lvmetad OTOH, lvmcache_label_scan() is basically a noop. IMO this should be fixed by adding a call to lvmcache_seed_infos_from_lvmetad() before applying the device filter to vgextend. vgcreate() calls it early on, right after lvmcache_label_scan(); the same might work for vgextend as well. Alternatively, it might be possible to add a call to lvmcache_seed_infos_from_lvmetad() to pvcreate_each_device(); in that case it might even be possible to remove the early calls in vgcreate(). I don't understand the initialization sequence of LVM2 commands well enough to create a patch myself. Besides vgextend, other LVM2 commands that need to apply the filter may be affected, too, as lvmcache_seed_infos_from_lvmetad() seems to be used only in a few hand- selected code paths. I suspect that this problem came to be in David's "label_scan" patch series in April 2018. But we haven't verified that yet. I've put David on CC. > > analysis: > > vgextend log excerpt: the aliases DB is built up _after_ applying > the I've put > filter, which falsely rejects the device. > ```log > lvmcmdline.c:2888 Processing command: vgextend -vvvv -dddddd -t > testvg /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3 > device/dev-cache.c:723 Found dev 8:35 > /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3 - new. > filters/filter-regex.c:172 > /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3: > Skipping > (regex) > filters/filter-persistent.c:346 filter caching bad > /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3 > ... > device/dev-cache.c:1212 Creating list of system devices. > device/dev-cache.c:763 Found dev 8:35 /dev/sdc3 - new alias > device/dev-cache.c:763 Found dev 8:35 > /dev/disk/by-id/iscsi-iqn.2018-06.de.suse.mwilck:sles15u-sp1- > 01_i_iface:default-1--iqn.2018-06.de.suse.zeus:01_t_0x1-lun-3-part3 > - new alias. > ``` > > vgcreate: the aliases DB is built up before applying the filter, > which > works correctly now. > ```log > lvmcmdline.c:2888 Processing command: vgcreate -vvvv -dddddd -t > tvg1 /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3 > device/dev-cache.c:1212 Creating list of system devices. > device/dev-cache.c:723 Found dev 8:35 /dev/sdc3 - new. > device/dev-cache.c:763 Found dev 8:35 > /dev/disk/by-id/iscsi-iqn.2018-06.de.suse.mwilck:sles15u-sp1- > 01_i_iface:default-1--iqn.2018-06.de.suse.zeus:01_t_0x1-lun-3-part3 > - new alias. > filters/filter-persistent.c:312 /dev/sdc3: filter cache using > (cached good) > ``` > > pvcreate will convert "/dev/disk/by-id/xxx" into another name > "/dev/sdX", which can pass the filter rule. A bit more precisely: when running pvcreate (or vgcreate), by the time the filter is called, "/dev/sdX" has been added to the list of aliases and thus the device is accepted, whereas in a vgextend run, the list of aliases has not been built up yet, and contains only a single member "/dev/disk/by-id/...", which is rejected. Regards, Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [linux-lvm] confused with lvm2 filter rules 2019-06-25 7:56 ` Martin Wilck @ 2019-06-25 8:56 ` Zdenek Kabelac 2019-06-25 9:13 ` Heming Zhao 0 siblings, 1 reply; 13+ messages in thread From: Zdenek Kabelac @ 2019-06-25 8:56 UTC (permalink / raw) To: LVM general discussion and development, Martin Wilck, Heming Zhao Dne 25. 06. 19 v 9:56 Martin Wilck napsal(a): > Hello Zdenek, > > On Tue, 2019-06-25 at 05:30 +0000, Heming Zhao wrote: >> Hello Zdenek, >> >> I raise this topic again. Lvm should have bug in filter code. >> Let me show the example. >> >> filter = [ "a|^/dev/sd.*|", "r|.*|" ] >> As document description, above filter rules: >> deny all the devices except "/dev/sd.*" >> >> issue: >> pvcreate executes successfully with "/dev/disk/by-id/xxx", but >> vgextend doesn't. >> >> expect result: >> pvcreate should deny the device "/dev/disk/by-id/xxx". >> > > I disagree with Heming in this point. IMO both pvcreate and vgextend > should accept the device because of the first "a" rule. In any case, > it's obviously wrong that the two tools behave differently. > > Note also that this difference occurs only if lvmetad is used. Without > lvmetad, both commands accept the device. The reason is that in this > case, lvmcache_label_scan(), which also builds the alias tree, is > called before applying the filter. With lvmetad OTOH, > lvmcache_label_scan() is basically a noop. > > IMO this should be fixed by adding a call to > lvmcache_seed_infos_from_lvmetad() before applying the device filter to > vgextend. vgcreate() calls it early on, right after > lvmcache_label_scan(); the same might work for vgextend as well. > Alternatively, it might be possible to add a call to > lvmcache_seed_infos_from_lvmetad() to pvcreate_each_device(); in that > case it might even be possible to remove the early calls in vgcreate(). > I don't understand the initialization sequence of LVM2 commands well > enough to create a patch myself. Besides vgextend, other LVM2 commands > that need to apply the filter may be affected, too, as > lvmcache_seed_infos_from_lvmetad() seems to be used only in a few hand- > selected code paths. > > I suspect that this problem came to be in David's "label_scan" patch > series in April 2018. But we haven't verified that yet. I've put David > on CC. > >> >> analysis: >> >> vgextend log excerpt: the aliases DB is built up _after_ applying >> the I've put >> filter, which falsely rejects the device. >> ```log >> lvmcmdline.c:2888 Processing command: vgextend -vvvv -dddddd -t >> testvg /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3 >> device/dev-cache.c:723 Found dev 8:35 >> /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3 - new. >> filters/filter-regex.c:172 >> /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3: >> Skipping >> (regex) >> filters/filter-persistent.c:346 filter caching bad >> /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3 >> ... >> device/dev-cache.c:1212 Creating list of system devices. >> device/dev-cache.c:763 Found dev 8:35 /dev/sdc3 - new alias >> device/dev-cache.c:763 Found dev 8:35 >> /dev/disk/by-id/iscsi-iqn.2018-06.de.suse.mwilck:sles15u-sp1- >> 01_i_iface:default-1--iqn.2018-06.de.suse.zeus:01_t_0x1-lun-3-part3 >> - new alias. >> ``` >> >> vgcreate: the aliases DB is built up before applying the filter, >> which >> works correctly now. >> ```log >> lvmcmdline.c:2888 Processing command: vgcreate -vvvv -dddddd -t >> tvg1 /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3 >> device/dev-cache.c:1212 Creating list of system devices. >> device/dev-cache.c:723 Found dev 8:35 /dev/sdc3 - new. >> device/dev-cache.c:763 Found dev 8:35 >> /dev/disk/by-id/iscsi-iqn.2018-06.de.suse.mwilck:sles15u-sp1- >> 01_i_iface:default-1--iqn.2018-06.de.suse.zeus:01_t_0x1-lun-3-part3 >> - new alias. >> filters/filter-persistent.c:312 /dev/sdc3: filter cache using >> (cached good) >> ``` >> >> pvcreate will convert "/dev/disk/by-id/xxx" into another name >> "/dev/sdX", which can pass the filter rule. > > A bit more precisely: when running pvcreate (or vgcreate), by the time > the filter is called, "/dev/sdX" has been added to the list of aliases > and thus the device is accepted, whereas in a vgextend run, the list of > aliases has not been built up yet, and contains only a single member > "/dev/disk/by-id/...", which is rejected. > Please open bugzilla with your findings: https://bugzilla.redhat.com/enter_bug.cgi?product=LVM%20and%20device-mapper Thanks Zdenek ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [linux-lvm] confused with lvm2 filter rules 2019-06-25 8:56 ` Zdenek Kabelac @ 2019-06-25 9:13 ` Heming Zhao 2019-06-26 6:49 ` Heming Zhao 0 siblings, 1 reply; 13+ messages in thread From: Heming Zhao @ 2019-06-25 9:13 UTC (permalink / raw) To: Zdenek Kabelac, LVM general discussion and development, Martin Wilck Hello All, I will fire this bug. On 6/25/19 4:56 PM, Zdenek Kabelac wrote: > Dne 25. 06. 19 v 9:56 Martin Wilck napsal(a): >> Hello Zdenek, >> >> On Tue, 2019-06-25 at 05:30 +0000, Heming Zhao wrote: >>> Hello Zdenek, >>> >>> I raise this topic again. Lvm should have bug in filter code. >>> Let me show the example. >>> >>> filter = [ "a|^/dev/sd.*|", "r|.*|" ] >>> As document description, above filter rules: >>> deny all the devices except "/dev/sd.*" >>> >>> issue: >>> pvcreate executes successfully with "/dev/disk/by-id/xxx", but >>> vgextend doesn't. >>> >>> expect result: >>> pvcreate should deny the device "/dev/disk/by-id/xxx". >>> >> >> I disagree with Heming in this point. IMO both pvcreate and vgextend >> should accept the device because of the first "a" rule. In any case, >> it's obviously wrong that the two tools behave differently. >> >> Note also that this difference occurs only if lvmetad is used. Without >> lvmetad, both commands accept the device. The reason is that in this >> case, lvmcache_label_scan(), which also builds the alias tree, is >> called before applying the filter. With lvmetad OTOH, >> lvmcache_label_scan() is basically a noop. >> >> IMO this should be fixed by adding a call to >> lvmcache_seed_infos_from_lvmetad() before applying the device filter to >> vgextend. vgcreate() calls it early on, right after >> lvmcache_label_scan(); the same might work for vgextend as well. >> Alternatively, it might be possible to add a call to >> lvmcache_seed_infos_from_lvmetad() to pvcreate_each_device(); in that >> case it might even be possible to remove the early calls in vgcreate(). >> I don't understand the initialization sequence of LVM2 commands well >> enough to create a patch myself. Besides vgextend, other LVM2 commands >> that need to apply the filter may be affected, too, as >> lvmcache_seed_infos_from_lvmetad() seems to be used only in a few hand- >> selected code paths. >> >> I suspect that this problem came to be in David's "label_scan" patch >> series in April 2018. But we haven't verified that yet. I've put David >> on CC. >> >>> >>> analysis: >>> >>> vgextend log excerpt: the aliases DB is built up _after_ applying >>> the I've put >>> filter, which falsely rejects the device. >>> ```log >>> lvmcmdline.c:2888 Processing command: vgextend -vvvv -dddddd -t >>> testvg /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3 >>> device/dev-cache.c:723 Found dev 8:35 >>> /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3 - new. >>> filters/filter-regex.c:172 >>> /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3: >>> Skipping >>> (regex) >>> filters/filter-persistent.c:346 filter caching bad >>> /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3 >>> ... >>> device/dev-cache.c:1212 Creating list of system devices. >>> device/dev-cache.c:763 Found dev 8:35 /dev/sdc3 - new alias >>> device/dev-cache.c:763 Found dev 8:35 >>> /dev/disk/by-id/iscsi-iqn.2018-06.de.suse.mwilck:sles15u-sp1- >>> 01_i_iface:default-1--iqn.2018-06.de.suse.zeus:01_t_0x1-lun-3-part3 >>> - new alias. >>> ``` >>> >>> vgcreate: the aliases DB is built up before applying the filter, >>> which >>> works correctly now. >>> ```log >>> lvmcmdline.c:2888 Processing command: vgcreate -vvvv -dddddd -t >>> tvg1 /dev/disk/by-id/scsi-36001405bbbdf17a69ad46ffb287a3340-part3 >>> device/dev-cache.c:1212 Creating list of system devices. >>> device/dev-cache.c:723 Found dev 8:35 /dev/sdc3 - new. >>> device/dev-cache.c:763 Found dev 8:35 >>> /dev/disk/by-id/iscsi-iqn.2018-06.de.suse.mwilck:sles15u-sp1- >>> 01_i_iface:default-1--iqn.2018-06.de.suse.zeus:01_t_0x1-lun-3-part3 >>> - new alias. >>> filters/filter-persistent.c:312 /dev/sdc3: filter cache using >>> (cached good) >>> ``` >>> >>> pvcreate will convert "/dev/disk/by-id/xxx" into another name >>> "/dev/sdX", which can pass the filter rule. >> >> A bit more precisely: when running pvcreate (or vgcreate), by the time >> the filter is called, "/dev/sdX" has been added to the list of aliases >> and thus the device is accepted, whereas in a vgextend run, the list of >> aliases has not been built up yet, and contains only a single member >> "/dev/disk/by-id/...", which is rejected. >> > > > Please open bugzilla with your findings: > > https://bugzilla.redhat.com/enter_bug.cgi?product=LVM%20and%20device-mapper > > Thanks > > Zdenek > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [linux-lvm] confused with lvm2 filter rules 2019-06-25 9:13 ` Heming Zhao @ 2019-06-26 6:49 ` Heming Zhao 0 siblings, 0 replies; 13+ messages in thread From: Heming Zhao @ 2019-06-26 6:49 UTC (permalink / raw) To: LVM general discussion anddevelopment, Zdenek Kabelac, Martin Wilck For record, I filed bug url: https://bugzilla.redhat.com/show_bug.cgi?id=1723745 On 6/25/19 5:13 PM, Heming Zhao wrote: > Hello All, > > I will fire this bug. > > On 6/25/19 4:56 PM, Zdenek Kabelac wrote: >> Dne 25. 06. 19 v 9:56 Martin Wilck napsal(a): >>> Hello Zdenek, >>> >>> On Tue, 2019-06-25 at 05:30 +0000, Heming Zhao wrote: > _______________________________________________ > linux-lvm mailing list > linux-lvm@redhat.com > https://www.redhat.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ > ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-06-26 6:49 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-03 13:03 [linux-lvm] confused with lvm2 filter rules Heming Zhao 2019-06-05 2:41 ` Heming Zhao 2019-06-05 10:20 ` Zdenek Kabelac 2019-06-06 6:42 ` Heming Zhao 2019-06-06 8:16 ` Heming Zhao 2019-06-06 8:43 ` Zdenek Kabelac 2019-06-06 13:30 ` Heming Zhao 2019-06-06 13:51 ` Zdenek Kabelac 2019-06-10 2:43 ` Heming Zhao [not found] ` <60982841-fabc-71d9-b8b1-6d98b87ba738@suse.com> 2019-06-25 7:56 ` Martin Wilck 2019-06-25 8:56 ` Zdenek Kabelac 2019-06-25 9:13 ` Heming Zhao 2019-06-26 6:49 ` Heming Zhao
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).