From: Peter Rajnoha <prajnoha@redhat.com>
To: Richard Davies <richard.davies@elastichosts.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] devices.filter changed behaviour in 80ac8f37d6
Date: Mon, 7 Sep 2015 13:48:49 +0200 [thread overview]
Message-ID: <55ED79A1.3060205@redhat.com> (raw)
In-Reply-To: <55ED77AA.7030708@redhat.com>
On 09/07/2015 01:40 PM, Peter Rajnoha wrote:
> On 09/07/2015 09:30 AM, Peter Rajnoha wrote:
>> On 09/05/2015 01:56 PM, Chris Webb wrote:
>>> Our hosts use local md arrays as LVM2 PVs in a very straightforward way.
>>> They also have lots of slower iscsi devices which LVM shouldn't scan or
>>> touch, so we use a simple filter in lvm.conf:
>>>
>>> devices {
>>> filter = [ "a|^/dev/md.*|", "r|.*|" ]
>>> }
>>>
>>> Upon upgrading from lvm-2.02.106 to 2.02.129, commands like lvdisplay
>>> and lvs dramatically slowed down. Investigating, we found the filter
>>> wasn't excluding the unwanted devices anymore: they were being scanned
>>> despite being explicitly excluded.
>>>
>>
>> I'll check it, thanks for the report...
>>
>
> OK, I've refreshed my memory now on this topic...
>
> I'd advise you to use global_filter instead which should do the job
> you need as global_filter is always evaluated at the beginning of the filter
> chain. It's also more appropriate to use global_filter in your case if you
> want to be sure that devices are filtered completely all the time, never
> scanned, even if you switched to using lvmetad.
Note:
Since lvm2 v2.02.116, we have a new feature in LVM which causes it
to reuse existing scanned information from udev database. See also
"devices/external_device_info_source" setting in lvm.conf. If you
switch that from "none" (default) to "udev", lots of the information
used for filtering is gathered from udev database, hence avoiding
the scans which are already done by udev (and mostly the blkid
call while processing udev rules).
This can avoid scanning for partition tables and md component
scanning which takes probably the most time (other scans do not
read from the disk directly, but they read information from /sysfs
and/or they do operations on devices via ioctl).
So besides filtering out some devices completely just because
of the time it takes to scan the device, you can also try the
"udev" external device info source to be used by LVM instead
so LVM doesn't gather the same info again when it's already
in udev database.
--
Peter
next prev parent reply other threads:[~2015-09-07 11:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-05 11:56 [linux-lvm] devices.filter changed behaviour in 80ac8f37d6 Chris Webb
2015-09-07 7:30 ` Peter Rajnoha
2015-09-07 11:40 ` Peter Rajnoha
2015-09-07 11:48 ` Peter Rajnoha [this message]
2015-09-07 13:01 ` Chris Webb
2015-09-07 13:08 ` Chris Webb
2015-09-07 13:23 ` Peter Rajnoha
2015-09-07 13:35 ` Peter Rajnoha
2015-09-07 14:00 ` Chris Webb
2015-09-07 14:12 ` Peter Rajnoha
2015-09-07 13:14 ` Peter Rajnoha
2015-09-07 13:44 ` Chris Webb
2015-09-07 13:54 ` Peter Rajnoha
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=55ED79A1.3060205@redhat.com \
--to=prajnoha@redhat.com \
--cc=linux-lvm@redhat.com \
--cc=richard.davies@elastichosts.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).