From: David Teigland <teigland@redhat.com>
To: "heming.zhao@suse.com" <heming.zhao@suse.com>
Cc: linux-lvm@redhat.com
Subject: Re: [linux-lvm] commit c527a0cbfc3 may have a bug
Date: Fri, 14 Feb 2020 13:11:15 -0600 [thread overview]
Message-ID: <20200214191115.GA20792@redhat.com> (raw)
In-Reply-To: <098d6e8d-2d2c-5067-1435-eefd7e2d09bc@suse.com>
On Fri, Feb 14, 2020 at 11:13:04PM +0800, heming.zhao@suse.com wrote:
> Hello list & David,
>
> The stable-2.02 branch commit c527a0cbfc391645d30407d2 may intruduce a bug.
> There is a new function label_scan_pvscan_all(), which uses
> cmd->lvmetad_filter to create devices list for scan.
>
> code:
> ```
> label_scan_pvscan_all
> if (!(iter = dev_iter_create(cmd->lvmetad_filter, 0)))
> ... ...
> while ((dev = dev_iter_get(iter)))
> ... ...
> ```
>
> It looks it is wrong to use cmd->lvmetad_filter in label_scan_pvscan_all.
> The behaviour is changed after the patch applied. (legacy code use
> cmd->full_filter)
Hi, it looks like a bug led to an incorrect filter configuration actually
working for a period of time. When the bug was later fixed, the incorrect
filter became apparent. In summary, the correct way to exclude devs from
lvmetad (and to handle duplicate PVs) is to set global_filter; filter is
not meant to work for that.
Here's the best comment to refer to:
* - cmd->lvmetad_filter - the lvmetad filter chain used when scanning devs for lvmetad update:
* sysfs filter -> internal filter -> global regex filter -> type filter ->
* usable device filter(FILTER_MODE_PRE_LVMETAD) ->
* mpath component filter -> partitioned filter ->
* md component filter -> fw raid filter
*
* - cmd->filter - the filter chain used for lvmetad responses:
* persistent filter -> regex_filter -> usable device filter(FILTER_MODE_POST_LVMETAD)
*
* - cmd->full_filter - the filter chain used for all the remaining situations:
* cmd->lvmetad_filter -> cmd->filter
pvscan --cache, which populates lvmetad, should be using
cmd->lvmetad_filter (which includes global_filter config, but not the
filter config.) So, label_scan_pvscan_all() looks like it should be
correct.
Before c527a0cbfc391645d30407d2, pvscan --cache called label_scan() which
uses cmd->full_filter (a combination of global_filter config and filter
config.) Afterward, pvscan --cache calls label_scan_pvscan_all() which
uses cmd->lvmetad_filter. So, that commit should be fixing the behavior
of pvscan.
> When system has duplicated devices and startup, with patch c527a0cb, the
> duplicated devs will pass global_filter (usually it's empty). It makes
> lvmetad fail to build up LV, then the system boot failed. This case is not
> my imagination, one of our customer met recently.
Setting global_filter is the correct way to handle duplicate devices,
setting the filter config shouldn't affect pvscan --cache.
> So I suggest to change the cmd->lvmetad_filter to cmd->full_filter in
> label_scan_pvscan_all().
>
> The steps to reproduce:
> ```
> create a loop dev.
> use this loop to create some mapper devs. (share the same loop dev)
> pvcreate on these mapper devs
>
> # this cmd will output warning msg.
> pvscan --cache --config ' devices { filter = [ "r|/dev/loop0|" } '
> # this cmd will not output warning msg.
> pvscan --cache --config ' devices { filter = [ "a|/dev/loop0|" ]
> global_filter = [ "r|/dev/loop0|" ] } '
> ```
The best option would be:
pvscan --cache --config ' devices { global_filter = [ "r|/dev/loop0|" } '
I have /dev/loop0 and a dm wrapper of it called /dev/mapper/loop0idm.
The best config works as expected:
# pvscan --cache --config "devices {global_filter=[\"r|/dev/loop0|\"]}" -vvvv 2>&1| grep -e 'Scan metadata from' -e WARNING
#cache/lvmetad.c:2292 Scan metadata from dev /dev/loop1
#cache/lvmetad.c:2292 Scan metadata from dev /dev/loop2
#cache/lvmetad.c:2292 Scan metadata from dev /dev/mapper/loop0idm
This config should work, but setting filter is unnecessary:
# pvscan --cache --config "devices {filter=[\"a|/dev/loop0|\"] global_filter=[\"r|/dev/loop0|\"]}" -vvvv 2>&1| grep -e 'Scan metadata from' -e WARNING
#cache/lvmetad.c:2292 Scan metadata from dev /dev/loop1
#cache/lvmetad.c:2292 Scan metadata from dev /dev/loop2
#cache/lvmetad.c:2292 Scan metadata from dev /dev/mapper/loop0idm
This config is not expected to work:
# pvscan --cache --config "devices {filter=[\"r|/dev/loop0|\"]}" -vvvv 2>&1| grep -e 'Scan metadata from' -e WARNING
#cache/lvmetad.c:2292 Scan metadata from dev /dev/loop0
#cache/lvmetad.c:2292 Scan metadata from dev /dev/loop1
#cache/lvmetad.c:2292 Scan metadata from dev /dev/loop2
#cache/lvmetad.c:2292 Scan metadata from dev /dev/mapper/loop0idm
#cache/lvmcache.c:1615 WARNING: found device with duplicate /dev/mapper/loop0idm
#cache/lvmcache.c:1617 WARNING: Disabling lvmetad cache which does not support duplicate PVs.
#cache/lvmetad.c:2486 WARNING: Scan found duplicate PVs.
#pvscan.c:515 WARNING: Not using lvmetad because cache update failed.
next prev parent reply other threads:[~2020-02-14 19:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <098d6e8d-2d2c-5067-1435-eefd7e2d09bc@suse.com>
2020-02-14 15:18 ` [linux-lvm] commit c527a0cbfc3 may have a bug heming.zhao
2020-02-14 19:11 ` David Teigland [this message]
2020-02-14 19:34 ` Gionatan Danti
2020-02-14 20:40 ` David Teigland
2020-02-15 5:22 ` heming.zhao
2020-02-15 12:40 ` Zdenek Kabelac
2020-02-15 19:15 ` Gionatan Danti
2020-02-15 20:19 ` Zdenek Kabelac
2020-02-16 15:17 ` Gionatan Danti
2020-02-15 20:49 ` Chris Murphy
2020-02-16 15:28 ` Gionatan Danti
2020-02-15 19:07 ` Gionatan Danti
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200214191115.GA20792@redhat.com \
--to=teigland@redhat.com \
--cc=heming.zhao@suse.com \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).