Re: lvmpolld causes high cpu load issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2022-08-17 at 10:11 -0500, David Teigland wrote:
> On Wed, Aug 17, 2022 at 01:41:17PM +0000, Martin Wilck wrote:
> > I like the general idea of the udev watch. It is the magic that
> > causes
> > newly created partitions to magically appear in the system, which
> > is
> > very convenient for users and wouldn't work otherwise. I can see
> > that
> > it might be inappropriate for LVM PVs. We can discuss changing the
> > rules such that the watch is disabled for LVM devices (both PV and
> > LV).
> > I don't claim to overlook all possible side effects, but it might
> > be
> > worth a try. It would mean that newly created LVs, LV size changes
> > etc.
> > would not be visible in the system immediately. I suppose you could
> > work around that in the LVM tools by triggering change events after
> > operations like lvcreate.
> 
> I think it's worth looking into at least.  udev causes most of our
> major
> problems, and causes things to fall apart everywhere at scale.

My first proposal for a quick workaround for our customer looked like
this:

echo 'ENV{DM_UUID}=="mpath-*", OPTIONS+="nowatch"' >\
    /run/udev/rules.d/90-dm-watch.rules

It made the issue disappear. This is obviously not a general solution.
Rather than applying the rule to mpath devices, it would be useful to
apply it to PVs. 

lvm could create a temporary rule similar to this one before starting a
pvmove operation (and possibly other operations that involve a lot of
metadata writes). It could actually create a rule specific to those PVs
it's going to change, with minimal side effects. When cleaning up after
the operation, the temporary rule would be removed again, and one
uevent triggered in case some other process had made changes while the
events were blocked. IMO that would be quite a simple solution to the
issue.

Using --vgmetadatacopies is also a nice workaround, but apparently the
default is storing metadata on all PVs.

Regards
Martin

_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/





[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux