archive mirror
 help / color / mirror / Atom feed
From: Martin Wilck <>
To: LVM general discussion and development <>,
	Zdenek Kabelac <>,
	Heming Zhao <>
Cc: Martin Wilck <>, David Teigland <>
Subject: Re: [linux-lvm] confused with lvm2 filter rules
Date: Tue, 25 Jun 2019 09:56:24 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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/
> - 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/
> - 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.


Dr. Martin Wilck <>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

  parent reply	other threads:[~2019-06-25  7:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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]             ` <>
2019-06-25  7:56               ` Martin Wilck [this message]
2019-06-25  8:56                 ` Zdenek Kabelac
2019-06-25  9:13                   ` Heming Zhao
2019-06-26  6:49                     ` Heming Zhao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).