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