Dne 30. 06. 20 v 12:43 Hans de Goede napsal(a):
Hi,

On 6/30/20 12:27 PM, Zdenek Kabelac wrote:
Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a):
Hi,

On 6/30/20 11:42 AM, Zdenek Kabelac wrote:
Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a):
On 30.06.2020 11:23, Igor Raits wrote:
Sadly you can't have lvm2 not installed:

Yes, but it can be disabled.



I'm sorry but e.g. dmraid-activation still running on every Fedora
Workstation install, instead of it being event activated does not give
the impression of you paying attention.

Hi

dmraid has been obsoleted already many Fedoras back -  why it's still
installed on any LiveCD I've no idea...

AFAIK dmraid can probably handle a few very exotic hw raid devices
which are not supported by mdraid.

But as said dmraid has been put into dust many years back, and there
is zero activity put into this package.

But problems need to be solved properly - not by 'ad-hock'  hijacking correct configuration.

On a default Fedora install with typically either a single sata
or NVME disk, with a VG with a single PV on that single disk +
3 LVs for / /home and swap, lvm2-monitor.service is simply not
necessary. It does not do do anything useful as per the
dmeventd manpage.

On default - UNTIL lvm2 command contacts monitoring and asks to monitor a device, moniting service does precisely nothing - so nothing is really wasted
in terms of CPU cycles.

BTW - if someone really DOES care about CPU - I'd probably recommend to focus on packages like dnf/rpm/Firefox/Chrome/Thunderbird/cups and lot's of other where the amount of wasted energy is really high - and I can continue with
large amount of network traffic with package upgrading... but let's not
side-track this discussion too much.


In this case disk failure simply is fatal, as it is with a
raw partition install and there is no provisioning / snapshotting
which can run out of overcomitted diskspace.

Have I misunderstood something here, is my analysis correct that
in this case starting dmeventd has 0 added value ?

Yes - you are most likely missing that 'lvm2-monitoring' does something only when it's in-use.

In the old history days without the systemd world - these monitoring service were forked exactly at the moment user has activated them - now in the systemd world where the services are supposed to be handled by systemd - lvm2 simply follows given rules - and we have the service which is contacted by lvm2
and service starts to work at the moment there is something to monitor.
Has this design changed again?

AFAIK there is nothing wasted - service is there (just like gazzilion of other systemd services nowadays).

As mentioned before - if someone is worried about having systemd lvm2 monitoring service in the system - he likely doesn't want to have lvm2 on his system at all - then the correct fix is to make sure - packages are properly packaged in a way they also work without lvm2 installed on system.

What is surely not our plan is that with each activation lvm2 command would be reevaulating systemd services and would be notifying users that their
systems needs service enabling  - lvm2 considers user has simply prohibited
monitoring - such usage is supported - user will just miss important modification or some functionality.

Installed lvm2 simply means present lvm2 services - nothing more nothing less.
Maybe we could provide some 'explicit' package for such services - but we would surely like to have such package installed by default.

But this is not about udev-settle, this is about lvm2-monitor.service
running on millions of systems where it really is not necessary.

IMHO see the above where the energy (and outcomes) are way more valuable....

With that said I can file a bug for this if you think that that will
help.

Yes please - if you have a system which does not need monitoring
and the monitoring slows down your boot considerably - then surely open BZ.
It should not be happening and it's likely a bug somewhere.
But that needs logs & analysis.

monitoring of non-existent raid-sets and non-existent thin-provisioning
should be disabled. The problem is that the lvm2-monitor.service runs
even if there are no dm raid sets and no thin-provisioning/snapshotting
clearly in that case the right thing would be to not run it?

ATM we are not recommending users to enable services themselves once the come to conclusion they need it - we consider them granted from installation of package.

1.) If the user does not need lvm2 - it should not be installed.
2.) If the skilled! user is 100% sure he does not need monitoring while he uses lvm2 - he can disable service - that's out current default view.

If there something is wrong in those 2 statements - let's open BZ and discuss the issues.

Zdenek
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Reply via email to