[linux-lvm] devices.filter changed behaviour in 80ac8f37d6

[Peter Rajnoha]

On 09/07/2015 03:01 PM, Chris Webb wrote:
> Peter Rajnoha <prajnoha at redhat.com> wrote:
> 
>> 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.
> 
> Hi Peter. Yes, we switched our config to use global_filter when we hit
> the problem. Great to hear that's the more efficient way to leave it
> long-term anyway. (global_filter didn't exist as an option when I last
> touched that lvm.conf, but it definitely makes sense to be able to
> restrict the device tree before any other, potentially expensive,
> processing.)
> 
> We should probably look at running the new lvmetad ourselves too: thanks
> for the pointer. We do quite a few read only queries from our management
> layer using lvs, vgs and so on. Caching the meta data between
> invocations could make a lot of sense if the daemon's reasonably
> lightweight and doesn't pull in extra dependencies. (LVM can't
> interrogate our udev database, though, as we don't use udev to handle
> our kernel uevents.)

Yes, without lvmetad daemon, each LVM command needs to run full device
scan at its start to look for PVs and then when a PV is found, it needs
to read all LVM metadata it finds (and check for consistency etc etc).
Of course, not including those devices which are filtered out.

However, with lvmetad, you can save some disk access here since all the
metadata are taken from lvmetad cache...

If you're not using udev to handle kernel uevents (hmm, what are you using
then?), then you need to make sure that whatever is processing the uevents,
it needs to do the same or similar job as usual udev rules would do with udev.
See also https://git.fedorahosted.org/cgit/lvm2.git/tree/udev/69-dm-lvm-metad.rules.in.

That means, you need to make sure that lvmetad knows about each new PV
that appears - normally we run "pvscan --cache major:minor" to do this -
this is triggered on uevents.

For now, we officially support only udev with lvmetad. Lvmetad doesn't have
any extra deps except what lvm binary already has.

-- 
Peter