Peter Rajnoha <prajnoha@redhat.com> wrote:
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...
Lvmetad doesn't have any extra deps except what lvm binary already has.
Sounds like a clear performance win for us. I'll have a play.
If you're not using udev to handle kernel uevents (hmm, what are you using
then?)
Nothing particularly clever or interesting I'm afraid: just a very trivial
daemon which translates events from a NETLINK_KOBJECT_UEVENT socket into a
continuous blocking stream.
https://github.com/arachsys/init/blob/master/uevent.c
This is then consumed by a simple read loop to implement the handful of
rules we actually want.
It'd be easy to add pvscan --cache when the relevant devices appear or
disappear. Thanks for the pointer.
(I note from the pvscan(8) man page that global_filter applies to pvscan
--cache but not standard filter, which sounds like another good reason to
switch to global_filter!)
Cheers,
Chris.
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
