Re: [linux-lvm] lvmpolld causes high cpu load issue

[Demi Marie Obenour <demi@invisiblethingslab.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Aug 17, 2022 at 05:26:08PM +0200, Zdenek Kabelac wrote:
> Dne 17. 08. 22 v 15:41 Martin Wilck napsal(a):
> > On Wed, 2022-08-17 at 14:54 +0200, Zdenek Kabelac wrote:
> > > Dne 17. 08. 22 v 14:39 Martin Wilck napsal(a):
> > > 
> > > 
> > > Let's make clear we are very well aware of all the constrains
> > > associated with
> > > udev rule logic  (and we tried quite hard to minimize impact -
> > > however udevd
> > > developers kind of 'misunderstood'  how badly they will be impacting
> > > system's
> > > performance with the existing watch rule logic - and the story kind
> > > of
> > > 'continues' with  'systemd's' & dBus services unfortunatelly...
> > 
> > I dimly remember you dislike udev ;-)
> 
> Well it's not 'a dislike' from my side - but the architecture alone is just
> missing in many areas...
> 
> Dave is a complete disliker of udev & systemd all together :)....

I find udev useful for physical devices, but for virtual devices it is a
terrible fit.  It is far too slow and full of race conditions.

Ideally, device-mapper ioctls would use diskseq instead of major+minor
number everywhere, and devices would be named after the diskseq.

> > 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
> 
> Tragedy of design comes from the plain fact that there are only 'very
> occasional' consumers of all these 'collected' data - but gathering all the
> info and keeping all of it 'up-to-date' is getting very very expensive and
> can basically 'neutralize' a lot of your CPU if you have too many resources
> to watch and keep update.....
> 
> 
> > 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).
> 
> It's really not fixable as is - since of the complete lack of 'error'
> handling of device in udev DB (i.e. duplicate devices...., various frozen
> devices...)
> 
> There is on going  'SID' project - that might push the logic somewhat
> further, but existing 'device' support logic as is today is unfortunate
> 'trace' of how the design should not have been made - and since all
> 'original' programmers left the project long time ago - it's non-trivial to
> push things forward.

What is the SID project, what are its goals, and how does it plan to
achieve them?

- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmL9EEEACgkQsoi1X/+c
IsEkLhAA0/7E1rP44bEFCK76JzKvevdlxe7sRBEPvgn/1m9SiEntC47QiEjnQeNi
cI9RLmHUlpYRghfDQMq8vhKk6a+NbnGsWTx3jciqQph+5SSIfPW9VuNi9w0nlvwS
GPHLweMadCblWqXh8XP2RvJx1Z1QeXZ6kYbfMjhZdxY7a/vg0rXTh0XghSyrgfYs
lgFbcqdJbEX5q70OGds8rhxAbTiBKnPHh3z5aFTCN7ILXO4blRWcqhDvAk0w3SQf
lt5WgDBjZ+5gv2pNiNuwZIzqsgL6FDE4CcR+7JWlAakC1GcocVp87aoiR1hNGMob
ZQoGaivvIjqYwSkWUDUArS8ntcKRBr/mYBcm6WuGZFbWja6NT2tEVJ8vcXdr2x5W
DoPk7Vkj/Y9pOn2kcYQMKR1mGOQhq1AwimSHuzPOeWifUWM5BOkH7hS46Tyq2bZJ
BM/QjUQcnckyAgPRYu+OWP3IvfOU+bFdTKabaoNgtCT85mfgL65sr8kx23ikQeZb
RQ9VcbQnJceKrNsqBnCDE4Xegh96er4Gm+68Crdgs0adHOTcyC5937PPSVy99ls8
MbkdPEVGHe4L1TS8XhI6+NCf0oaFCVE/1vKeS4yO28VbSn/N3pbhiNF6cpc0sWDg
NA0mbIsl19t4j8CtXVCjPeh1+RULvXqhedQIC/xJF3FserAInkc=
=J7YY
-----END PGP SIGNATURE-----

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