Hi,
On 6/30/20 1:27 PM, Zdenek Kabelac wrote:
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.
Hmm, well on one hand that is good to know OTOH I'm pretty sure that
if we drop it we will cause issues for some users who rely on it,
it is basically needed for any kind of BIOS/firmware RAID which is
not Intel BIOS/firmware RAID. So it is e.g. needed for AMD BIOS/firmware
RAID. Unless this has changed ?
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.
Ok, so I just checked an you are right, in my memory I was
disabling this because it kept a running process around
doing nothing, but now I see:
[hans@x1 ~]$ sudo systemctl status lvm2-monitor.service
● lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeve>
Loaded: loaded (/usr/lib/systemd/system/lvm2-monitor.service; enabled; ven>
Active: active (exited) since Tue 2020-06-30 10:37:37 CEST; 3h 20min ago
Docs: man:dmeventd(8)
man:lvcreate(8)
man:lvchange(8)
man:vgchange(8)
Main PID: 903 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 18803)
Memory: 0B
CPU: 0
CGroup: /system.slice/lvm2-monitor.service
Ideally this would not start at all when not necessary, but
yes there is lower hanging fruit, sorry for the noise.
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.
Well it does start, only to immediately exit afterwards, which is ok, but
as mentioned ideally it would not start at all. But I agree that there
are bigger things to worry about then this.
<snip>
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.
So I was under the impressions that dmeventd (or some other process)
was always running, but I was wrong (and/or things have changed since
I last checked), sorry.
For me lvm2-monitor.service quickly exits using just 34mS CPU time.
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.
Well this one is a bit tricky, for one because even basic lvm support
(just VGs and LVs and nothing else) brings in support for all the
other less basic features which lvm/dm has.
And with livecd installs, the package-set which is on the livecd
is also what will end up being installed, even if the user has chosen
to use a raw partition (note since lvm is the default this is not a
big issue I guess).
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.
Agreed.
Regards,
Hans
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
