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.
Of course, you can disable this yourself if you are skilled admin and you do not need it or use it (you can mask it which is even better).
Default for unskilled users who may use lvm2 - should remain enabled.
So I just did some research on this and the lvm2-monitor.service name is somewhat
misleading. This service starts dmeventd (through lvm commands) and on most normal
lvm setups, as we create them with anaconda's default auto-partitioning dmeventd
is not necessary at all. Actually I use the auto-partitioning on all my systems
and I always disable lvm2-monitor.service without any bad side-effects.
man dmeventd helps a lot here, dmeventd monitors events on devices used by
device-mapper and acts on them through plugins the following plugins are
available (see man dmeventd and then the "LVM PLUGINS" section) :
mirrorring/raid -> In this case dmeventd attempts to handle device failure,
this is definitely good to have but only if mirroring/raid is used,
which in practice means that dmraid is used.
snapshot/thin/vdo -> dmeventd monitors if the storage pool is running out
of space and if it is it sends a warning to syslog. This maybe is somewhat
useful but only in combination with another monitoring system monitoring
syslog for these messages and pro-actively contacting the admin; and this
is only relevant if snapshot/thin/vdo lvm features are used, which in a
default Fedora install they are not.
So this is a third case (next to dmraid and device-mapper-multipath) of
a device-mapper/lvm related service which is always starting itself
(taking time and resources) needlessly on 99.9% of all Fedora workstation
installs.
I really wish that the lvm/device-mapper team would pay more attention
to this. As Lennart mentioned in the thread, the dmraid issue has been
a known issue for 10 years now and dmraid really need to be changed to
be activated based on blkid results rather then always start and scan
all disks.
My proposal for now for the lvm2-monitor.service is to change the
Workstation pre`set to disabled and to make dmraid-activation.service
have a Requires= on it.
This way for dmraid setups we keep the code attempting to deal with
disk-failure.
As for snapshot/thin/vdo we do not use that by default in Fedora workstation
and as mentioned logging a warning to syslog is not all that useful anyways
unless additional manual setup is done to automatically monitor syslog for
this, in which case enabling the service is just a tiny extra step when
already manually setting up the monitoring.
Hi
Of course we DO PAY attention (me being member of lvm2 team)!
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.
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.
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 ?
There are many different types of configuration and each need to be taken care separately.
ATM - if you do not have lvmetad (which has been used on older Fedoras for auto-actvation) there should not be a settle dependency on your boot path.
dmraid and device-mapper-multipath (bot also lvm2 team projects)
both bring in systemd-udev-settle.service. The plan for those
for livecds is to have anaconda disable them if they are unused,
see the dmraid thread.
But this is not about udev-settle, this is about lvm2-monitor.service
running on millions of systems where it really is not necessary.
So if we want to track this out properly - I'd simply highly recommend
to open BZ for the issue and provide correct logs for analysis.
There are no case specific logs here any default Fedora Workstation
install has lvm2-monitor.service running, where as I tried to explain
above with the lvm features used by the default install, this is not
necessary and has 0 added value.
With that said I can file a bug for this if you think that that will
help.
It's not solving any issue if you just stating 'monitoring should be disable by default' - as monitoring itself should simply not slow down anything and for some use case it's pretty mandatory to have this service enabled.
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?
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
