Dne 30. 06. 20 v 12:43 Hans de Goede napsal(a):
On 6/30/20 12:27 PM, Zdenek Kabelac wrote:
Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a):
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.
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
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
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
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
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
devel mailing list -- email@example.com
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines