[linux-lvm] unable to exclude LVs using global_filter

[Gordon Messmer]

On 01/02/2018 10:17 AM, Marian Csontos wrote:
> I do not think that log shows what is processed. LVM displays device 
> names according to different option - preferred_names it is.

I see.  It seems to me that, for the purpose of troubleshooting filter 
processing, the literal path that matches a filter option should be logged.

> If lvmetad is in use, which by default it is, run `pvscan -vvvv 
> --cache $DEV_MAJOR:$DEV_MINOR` - that should be more helpful WRT which 
> devices are scanned and accepted as Physical Volumes.

I see the following in the ouptut:

#device/dev-cache.c:356         /dev/dm-3: Added to device cache (253:3)
#device/dev-cache.c:352         /dev/VolGroup/vm_wiki_data: Aliased to 
/dev/dm-3 in device cache (preferred name) (253:3)
#device/dev-cache.c:352 /dev/disk/by-id/dm-name-VolGroup-vm_wiki_data: 
Aliased to /dev/VolGroup/vm_wiki_data in device cache (253:3)
#device/dev-cache.c:352 
/dev/disk/by-id/dm-uuid-LVM-LaE2AjV9UKn6sAhmbduHGzY0TsRtfr9fwKOoFpMNpYX98umwKoXfH0qQb2MG7bCx: 
Aliased to /dev/VolGroup/vm_wiki_data in device cache (253:3)
#device/dev-cache.c:352 
/dev/disk/by-id/lvm-pv-uuid-NRKTXX-I9D8-Vxb1-hKcX-rjJX-GNhB-jgsXiW: 
Aliased to /dev/VolGroup/vm_wiki_data in device cache (253:3)
#device/dev-cache.c:352         /dev/mapper/VolGroup-vm_wiki_data: 
Aliased to /dev/VolGroup/vm_wiki_data in device cache (253:3)

...understanding that all of those paths are filtered individually was 
the bit I was missing.

> IMHO the documentation is confusing if not straight incorrect. I hate 
> that and IMHO we should fix how the filtering works, but that would be 
> an incompatible change, and those are not loved. :-(
>
> How it actually works is: if ANY path is accepted, the device is. In 
> upstream the lvm.conf also says (emphasis mine):
>
> "When multiple path names exist for a block device, if *any path* name 
> matches an 'a' pattern before an 'r' pattern, then the device is 
> accepted. If all the path names match an 'r' pattern first, then the 
> device is rejected."

The description of filtering is... maybe a touch long, and that specific 
bit is very important and easy to miss.  It might be more clear to move 
that statement to a paragraph of its own.

Alternatively, if devices are accepted when no pattern matches, maybe 
emptying the default filter would be a better approach.  That way the 
default configuration would accept all devices.  If someone introduces 
an r filter, it will actually work as expected.  It's nearly impossible 
to effectively blacklist a device if the default "a" filter is retained, 
and it doesn't appear to serve a function if the system accepts block 
devices that match no path.

> May be we should replace the "device" in the last sentence by "path" 
> so it would say:
>
> "The first regex in the list to match the path is used, producing the 
> 'a' or 'r' result for *that path*."

I'm not sure that really conveys the bit that I, personally, missed, 
which is that in order to reject a device, you must reject all of the 
paths by which it is referenced.  If the default "a" filter is retained, 
then you'd probably want to be clear about that, and possibly describe 
at least one way to get a list of all of the paths that lead to a given 
block device.

Thanks for the help understanding the filter system.  I'll work with 
this a bit and come back if my understanding is still incorrect.