Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
3:04 p.m.
https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun
== Summary ==
The Fedora workstation livecd is the default Fedora variant getfedora.org
advices people to download.
As such most Fedora workstation installs will be done from the livecd. This
means that any package which is part of the livecd will be part of the
default install for most users.
Dmraid is 1 of only 2 packages in the default install which still Requires
the long obsoleted systemd-udev-settle.service, which waits for all
device-detection to be done + some extra waiting just to be sure. This
significantly slows down booting on various systems.
Fedora only support these RAID sets when they are already configured in the
BIOS at installation time. So we can solve the problem of dmraid.service
still depending on the obsolete udev-settle service by making
dmraid.service disable itself if no supported RAID sets are found on its
first run.
== Owner ==
* Name: [[User:jwrdegoede| Hans de Goede]]
* Email: hdegoede(a)redhat.com
== Detailed Description ==
Dmraid is 1 of only 2 packages in the default install which still Requires
the long obsoleted systemd-udev-settle.service. The other package is
device-mapper-multipath see
[[Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD|Remove
device-mapper-multipath from the Fedora workstation livecd]].
Dmraid is necessary to support firmware-raid (motherboard BIOS built-in
RAID support) for non Intel firmware RAID sets. These RAID sets are quite
rare and we have never supported configuring these RAID sets after the
installation without manually setting it up. Since we only support these
sets when they are already configured in the BIOS at installation time, we
can solve the problem of dmraid.service still depending on the obsolete
udev-settle service by making dmraid.service disable itself if no supported
RAID sets are found on its first run.
Note then when installing from the server or everything netboot isos,
dmraid depending on the obsolete udev-settle service is not a problem,
because then it will not be installed at all. Anaconda (the installer) adds
storage related packages such as dmraid to the installation package-set as
necessary for the storage found at installation time. This means that for
such installs, if a dmraid set is later configured, the user manually needs
to install dmraid to be able to use the RAID set. This change adds a
similar requirement to livecd installs, there the user will now need to do
a "systemctl enable dmraid.service" if a dmraid set is added to the system
later.
There has been [https://bugzilla.redhat.com/show_bug.cgi?id=1795014 a bug]
open against dmraid for this issue for a while now. As pointed out there,
this change can easily be implemented with some small changes to the shell
script which gets started by the dmraid service.
== Benefit to Fedora ==
systemd-udev-settle.service causes a significant and sometimes quite long
delay during boot. Removing / disabling the last 2 services depending on
this long obsolete helper service will remove the unnecessary boot delay.
== Scope ==
* Proposal owners:
** Prepare the suggested dmraid activation script changes and push out a
new dmraid package with these changes added
** Coordinate this with the dmraid maintainers
* Other developers:
** I will make sure that the dmraid maintainers are aware of and agree with
these changes. I will take care of these changes myself.
* Release engineering: [https://pagure.io/releng/issue/9559 #9559] (a check
of an impact with Release Engineering is needed)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
After upgrading, if no dmraid sets are found on the first boot with the new
package, the dmraid service will disable itself, just as it will on new F33
installs.
== How To Test ==
# Install F33 on a machine / VM without dmraid
# Boot the installed system
# Reboot the installed system
# Do "systemctl status dmraid.service", the output should be "loaded (...;
disabled; ...)" and "inactive (dead)"
== User Experience ==
Faster booting Fedora when installed from the livecd.
== Dependencies ==
There are no other changes / package updates this Change depends on; or
which this change impacts.
== Contingency Plan ==
* Contingency mechanism: Revert the activation script changes if they cause
problems
* Blocks release? No
== Documentation ==
This change does not require any documentation.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3:18 p.m.
On Mon, Jun 29, 2020 at 2:06 PM Ben Cotton <bcotton(a)redhat.com> wrote:
Fedora only support these RAID sets when they are already configured
in the BIOS at installation time. So we can solve the problem of dmraid.service still
depending on the obsolete udev-settle service by making dmraid.service disable itself if
no supported RAID sets are found on its first run.
Hurray! +1
--
Chris Murphy
3:30 p.m.
On Mon, Jun 29, 2020 at 4:05 PM Ben Cotton <bcotton(a)redhat.com> wrote:
https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun
== Summary ==
The Fedora workstation livecd is the default Fedora variant getfedora.org advices people
to download.
As such most Fedora workstation installs will be done from the livecd. This means that
any package which is part of the livecd will be part of the default install for most
users.
Dmraid is 1 of only 2 packages in the default install which still Requires the long
obsoleted systemd-udev-settle.service, which waits for all device-detection to be done +
some extra waiting just to be sure. This significantly slows down booting on various
systems.
Fedora only support these RAID sets when they are already configured in the BIOS at
installation time. So we can solve the problem of dmraid.service still depending on the
obsolete udev-settle service by making dmraid.service disable itself if no supported RAID
sets are found on its first run.
Yay! +1
--
真実はいつも一つ！/ Always, there's only one truth!
3:45 p.m.
So, in relation to the device-mapper-multipath change in the other
thread, I ran 'sudo dnf remove device-mapper-multipath'. Then I ran
'systemctl status dmraid.service' and saw "Unit dmraid.service could
not be found," so I must not have that installed at all. Then I
rebooted. When I run 'systemctl status systemd-udev-settle.service' I
see it's still active and exited after my reboot. I see the vendor
preset is disabled, so I guess it should be OK for fresh installs, but
maybe the current proposals won't be enough for upgraded systems? We
might need to explicitly disable systemd-udev-settle.service during the
system upgrade to turn it off?
3:57 p.m.
On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
We might need to explicitly disable systemd-udev-settle.service
during the system upgrade to turn it off?
Doesn't work... I tried 'systemctl disable systemd-udev-settle.service'
and rebooted again, and it's still running. I tried 'systemd-analyze
plot' and I see it takes 11 seconds during boot! I think the culprit is
dmraid-activation.service (not dmraid.service). Did you get the name of
the service wrong in the change proposal, or have I misunderstood?
Unrelated: looking at my systemd-analyze plot, other startup time
offenders are NetworkManager-wait-online.service (9.5 seconds, seems
egregious, I wonder why this is necessary?) and grand prize winner
abrtd.service (requiring an amazing 30 seconds!)
4:09 p.m.
Hi,
On 6/29/20 10:57 PM, Michael Catanzaro wrote:
On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
> We might need to explicitly disable systemd-udev-settle.service during the system
upgrade to turn it off?
Doesn't work... I tried 'systemctl disable systemd-udev-settle.service' and
rebooted again, and it's still running. I tried 'systemd-analyze plot' and I
see it takes 11 seconds during boot! I think the culprit is dmraid-activation.service (not
dmraid.service). Did you get the name of the service wrong in the change proposal, or have
I misunderstood?
I got the name of the unit wrong in the change proposal, sorry. I fix this on my
own systems with "dnf remove dmraid", but unlike multipath some desktop
machines
may actually have a BIOS/firmware RAID set configured which needs dmraid and we
do want to support those setups with the workstation livecd.
I'll re-install dmraid and correct the proposal text when I can find some time
for that.
Regards,
Hans
4:16 p.m.
On Mon, Jun 29, 2020 at 11:09 pm, Hans de Goede <hdegoede(a)redhat.com>
wrote:
I got the name of the unit wrong in the change proposal, sorry. I fix
this on my
own systems with "dnf remove dmraid", but unlike multipath some
desktop machines
may actually have a BIOS/firmware RAID set configured which needs
dmraid and we
do want to support those setups with the workstation livecd.
I'll re-install dmraid and correct the proposal text when I can find
some time
for that.
OK cool. I just wanted to add, I tested and confirmed that if I
'systemctl disable dmraid-activation.service', it does indeed cause
systemd-udev-settle.service to no longer run, so seems to work nicely.
Next, I will test disabling ABRT and confirm we'll boot twice as fast
without it. :(
4:23 p.m.
On Mon, Jun 29, 2020 at 11:09 PM Hans de Goede <hdegoede(a)redhat.com> wrote:
I fix this on my
own systems with "dnf remove dmraid"
This tends to take with it many things that it shouldn't, like gdb,
dbus-x11, python3-pwquality, tigervnc-server-minimal and tmux - among
others.
6:34 p.m.
New subject: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Monday, 29 June 2020 22.23.00 WEST Alexander Ploumistos wrote:
This tends to take with it many things that it shouldn't, like
gdb,
dbus-x11, python3-pwquality, tigervnc-server-minimal and tmux - among
others.
I noticed that before but at least on F32 it does not do it anymore. I have
removed dmraid and I still have gdb and tmux installed.
--
José Abílio
6:56 p.m.
On Tue, Jun 30, 2020 at 1:35 AM José Abílio Matos <jamatos(a)fc.up.pt> wrote:
On Monday, 29 June 2020 22.23.00 WEST Alexander Ploumistos wrote:
> This tends to take with it many things that it shouldn't, like gdb,
> dbus-x11, python3-pwquality, tigervnc-server-minimal and tmux - among
> others.
I noticed that before but at least on F32 it does not do it anymore. I have
removed dmraid and I still have gdb and tmux installed.
I just tested it on F32 Workstation and for me it does. Have you
cleaned dnf's databases by any chance? I think either that or having
the packages as dependencies of something that was installed by the
user would prevent them from going away with dmraid.
3:25 a.m.
New subject: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Tuesday, 30 June 2020 00.56.23 WEST Alexander Ploumistos wrote:
I just tested it on F32 Workstation and for me it does. Have you
cleaned dnf's databases by any chance? I think either that or having
the packages as dependencies of something that was installed by the
user would prevent them from going away with dmraid.
I tried a reverse stance, notice that I have all the package that you mentioned
installed:
[root@myth ~]# dnf install gdb dbus-x11 python3-pwquality tigervnc-server-minimal tmux
Last metadata expiration check: 0:03:44 ago on Tue 30 Jun 2020 09:14:30 AM WEST.
Package gdb-9.1-5.fc32.x86_64 is already installed.
Package dbus-x11-1:1.12.18-1.fc32.x86_64 is already installed.
Package python3-pwquality-1.4.2-2.fc32.x86_64 is already installed.
Package tigervnc-server-minimal-1.10.1-5.fc32.x86_64 is already installed.
Package tmux-3.0a-2.fc32.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
[root@myth ~]# dnf remove dmraid
No match for argument: dmraid
No packages marked for removal.
Dependencies resolved.
Nothing to do.
Complete!
--
José Abílio
3:30 a.m.
New subject: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Tuesday, 30 June 2020 00.56.23 WEST Alexander Ploumistos wrote:
I just tested it on F32 Workstation and for me it does. Have you
cleaned dnf's databases by any chance? I think either that or having
the packages as dependencies of something that was installed by the
user would prevent them from going away with dmraid.
IIRC this is probably related with the dependencies of anaconda:
# repoquery --whatrequires 'dmraid' --recursive
Last metadata expiration check: 0:14:34 ago on Tue 30 Jun 2020 09:14:30 AM WEST.
anaconda-0:32.24.5-1.fc32.x86_64
anaconda-0:32.24.7-1.fc32.x86_64
anaconda-0:32.24.7-2.fc32.x86_64
anaconda-install-env-deps-0:32.24.5-1.fc32.x86_64
anaconda-install-env-deps-0:32.24.7-1.fc32.x86_64
anaconda-install-env-deps-0:32.24.7-2.fc32.x86_64
anaconda-realmd-0:0.2-12.fc32.noarch
dmraid-0:1.0.0.rc16-44.fc32.i686
dmraid-0:1.0.0.rc16-44.fc32.x86_64
dmraid-devel-0:1.0.0.rc16-44.fc32.x86_64
dmraid-events-0:1.0.0.rc16-44.fc32.x86_64
dmraid-events-logwatch-0:1.0.0.rc16-44.fc32.x86_64
kdump-anaconda-addon-0:005-8.20200220git80aab11.fc32.noarch
libblockdev-dm-0:2.23-2.fc32.i686
libblockdev-dm-0:2.23-2.fc32.x86_64
libblockdev-dm-0:2.24-1.fc32.i686
libblockdev-dm-0:2.24-1.fc32.x86_64
libblockdev-dm-devel-0:2.23-2.fc32.i686
libblockdev-dm-devel-0:2.23-2.fc32.x86_64
libblockdev-dm-devel-0:2.24-1.fc32.i686
libblockdev-dm-devel-0:2.24-1.fc32.x86_64
libblockdev-plugins-all-0:2.23-2.fc32.x86_64
libblockdev-plugins-all-0:2.24-1.fc32.x86_64
oscap-anaconda-addon-0:1.0-6.fc32.noarch
--
José Abílio
4:10 a.m.
On Tue, Jun 30, 2020 at 10:30 AM José Abílio Matos <jamatos(a)fc.up.pt> wrote:
IIRC this is probably related with the dependencies of anaconda:
Is there an easy suggestion we can make to our users other than play
with "rpm -e" or nuking dnf's database? There's a bunch of threads
over at askfedora where people are killing services left and right,
without knowing what they do, in order to shave off a few
milliseconds.
4:14 p.m.
On Mon, Jun 29, 2020 at 2:58 PM Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
> We might need to explicitly disable systemd-udev-settle.service
> during the system upgrade to turn it off?
Doesn't work... I tried 'systemctl disable systemd-udev-settle.service'
and rebooted again, and it's still running. I tried 'systemd-analyze
plot' and I see it takes 11 seconds during boot! I think the culprit is
dmraid-activation.service (not dmraid.service). Did you get the name of
the service wrong in the change proposal, or have I misunderstood?
Unrelated: looking at my systemd-analyze plot, other startup time
offenders are NetworkManager-wait-online.service (9.5 seconds, seems
egregious, I wonder why this is necessary?) and grand prize winner
abrtd.service (requiring an amazing 30 seconds!)
Many activate and run in parallel, including
NetworkManager-wait-online, and don't directly contribute to startup
delays. That one should really just be waiting for all the network
configuration to really happen before trying things that depend on the
network: e.g. NFS and maybe some kind of network login. Some services
can stuck much longer if they try to connect before there's a
connection available.
But yeah all of the enabled by default services probably need a review
for F33 to make sure they're intentionally enabled. /me not a fan of
startup delays, I really wanna be under 10s. Right now I'm at 19s and
that's on NVMe with no external devices or services to connect to.
--
Chris Murphy
5:37 p.m.
On 6/29/20 1:57 PM, Michael Catanzaro wrote:
On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
> We might need to explicitly disable systemd-udev-settle.service during
> the system upgrade to turn it off?
Doesn't work... I tried 'systemctl disable systemd-udev-settle.service'
and rebooted again, and it's still running. I tried 'systemd-analyze
plot' and I see it takes 11 seconds during boot! I think the culprit is
dmraid-activation.service (not dmraid.service). Did you get the name of
the service wrong in the change proposal, or have I misunderstood?
Unrelated: looking at my systemd-analyze plot, other startup time
offenders are NetworkManager-wait-online.service (9.5 seconds, seems
egregious, I wonder why this is necessary?) and grand prize winner
abrtd.service (requiring an amazing 30 seconds!)
But that should be running concurrently. Does the plot show anything
important waiting for it? Your desktop should be able to load before
that service is finished starting.
5:59 p.m.
On Mon, Jun 29, 2020 at 3:37 pm, Samuel Sieb <samuel(a)sieb.net> wrote:
But that should be running concurrently. Does the plot show
anything
important waiting for it? Your desktop should be able to load before
that service is finished starting.
Well notably: plymouth-quit-wait.service. Surely plymouth keeps running
until everything else has finished, right?
6:33 p.m.
On 6/29/20 3:59 PM, Michael Catanzaro wrote:
On Mon, Jun 29, 2020 at 3:37 pm, Samuel Sieb <samuel(a)sieb.net>
wrote:
> But that should be running concurrently. Does the plot show anything
> important waiting for it? Your desktop should be able to load before
> that service is finished starting.
Well notably: plymouth-quit-wait.service. Surely plymouth keeps running
until everything else has finished, right?
I would hope that gdm tells plymouth to go away or starts a new console
anyway, but that would be good to find out. There's no reason for
anything to be waiting for abrt to finish loading.
3:50 a.m.
Hi,
On 6/30/20 12:59 AM, Michael Catanzaro wrote:
On Mon, Jun 29, 2020 at 3:37 pm, Samuel Sieb <samuel(a)sieb.net>
wrote:
> But that should be running concurrently. Does the plot show anything
> important waiting for it? Your desktop should be able to load before
> that service is finished starting.
Well notably: plymouth-quit-wait.service. Surely plymouth keeps running until everything
else has finished, right?
plymouth-quit-wait.service is special. On gdm startup the following happens:
1. gdm tells plymouth to deactivate, at this point it release its drm-master
ownership of /dev/dri/card0, but does keep it open because otherwise the
kernel will automatically free the framebuffer installed by plymouth and
that would cause a flicker
2. gdm starts the greeter session
3. the greeter session lets gdm know that it has fully started, this means
that gdm now knows that either Xorg or mutter(Wayland) has /dev/dri/card0
open and has installed its own framebuffer
4. gdm tells plymouth it is ok to quit know (and thus close /dev/dri/card0)
Step 2 / reaching step 3. is what can take a long time here. This should
normally not be dependent on NetworkManager-wait-online.service though. I
guess the two just overlap.
Regards,
Hans
6:05 p.m.
New subject: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Monday, June 29, 2020 1:57:55 PM MST Michael Catanzaro wrote:
On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
> We might need to explicitly disable systemd-udev-settle.service
> during the system upgrade to turn it off?
Doesn't work... I tried 'systemctl disable systemd-udev-settle.service'
and rebooted again, and it's still running. I tried 'systemd-analyze
plot' and I see it takes 11 seconds during boot! I think the culprit is
dmraid-activation.service (not dmraid.service). Did you get the name of
the service wrong in the change proposal, or have I misunderstood?
Unrelated: looking at my systemd-analyze plot, other startup time
offenders are NetworkManager-wait-online.service (9.5 seconds, seems
egregious, I wonder why this is necessary?) and grand prize winner
abrtd.service (requiring an amazing 30 seconds!)
Well, disabling it on upgrade might be fine, so long as you check that it's
not actually in use. Please keep in mind that dmraid is required for, for
example, Intel firmware RAID, and so simply disabling this would mean that
users' workstations or servers using firmware RAID wouldn't be able to boot..
--
John M. Harris, Jr.
3:57 a.m.
On 29.06.2020 22:04, Ben Cotton wrote:
Fedora only support these RAID sets when they are already configured
in
the BIOS at installation time. So we can solve the problem of
dmraid.service still depending on the obsolete udev-settle service by
making dmraid.service disable itself if no supported RAID sets are found
on its first run.
+1 for this change.
Also the LVM monitor can be disabled too if LVM is not used in current
Fedora installation.
LVM monitor: -2.01 seconds.
RAID: -2.41 seconds.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:04 a.m.
Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a):
On 29.06.2020 22:04, Ben Cotton wrote:
> Fedora only support these RAID sets when they are already configured in
> the BIOS at installation time. So we can solve the problem of
> dmraid.service still depending on the obsolete udev-settle service by
> making dmraid.service disable itself if no supported RAID sets are found
> on its first run.
+1 for this change.
Also the LVM monitor can be disabled too if LVM is not used in current
Fedora installation.
LVM monitor: -2.01 seconds.
RAID: -2.41 seconds.
If the user does not need lvm2, then the package should not be installed/
However when lvm2 is installed - lvm2 monitoring service is supposed to
be there and enabled - it should not impact load time all that much...
Zdenek
4:18 a.m.
On 30.06.2020 11:04, Zdenek Kabelac wrote:
If the user does not need lvm2, then the package should not be
installed/
However when lvm2 is installed - lvm2 monitoring service is supposed to
be there and enabled - it should not impact load time all that much...
I use classic partitions, but lvm2-monitor.service is still enabled:
2.129s lvm2-monitor.service
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:23 a.m.
New subject: Disable dmraid.service on first run if no dmraid sets are found
- Fedora 33 System-Wide Change proposal
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Tue, 2020-06-30 at 11:04 +0200, Zdenek Kabelac wrote:
Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a):
> On 29.06.2020 22:04, Ben Cotton wrote:
> > Fedora only support these RAID sets when they are already
> > configured in
> > the BIOS at installation time. So we can solve the problem of
> > dmraid.service still depending on the obsolete udev-settle
> > service by
> > making dmraid.service disable itself if no supported RAID sets
> > are found
> > on its first run.
>
> +1 for this change.
>
> Also the LVM monitor can be disabled too if LVM is not used in
> current
> Fedora installation.
>
> LVM monitor: -2.01 seconds.
> RAID: -2.41 seconds.
If the user does not need lvm2, then the package should not be
installed/
However when lvm2 is installed - lvm2 monitoring service is supposed
to
be there and enabled - it should not impact load time all that
much...
❯ systemd-analyze blame | grep lvm
4.103s lvm2-monitor.service
Sadly you can't have lvm2 not installed:
lvm2 is needed by (installed) libvirt-daemon-driver-storage-
logical-6.4.0-1.fc33.x86_64
that is required by other libvirt stuff which ends up with gnome-boxes.
Zdenek
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
- --
Igor Raits <ignatenkobrain(a)fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77BK0ACgkQEV1auJxc
Hh4V8hAApS1m1x4gqE66qQZuf81bcHPU3wTYYgLvzqVr69eq25hzu1pIQDT1oXJH
WgHuucYKCQjr2JO9dv2Amil0hNlnrRP6AONJ28f22xUnUHoM93vYi7Y6Ba5sbGh6
31DRf5FEgfcBODXmB4XVGm2vXxlWeMYVnR9ujKHvnl/8ODrI6jLrvIDl02rFq3eT
Gym144modLy6cKVaUBRO8q6n26A8wHXKQ+9Gj7h95c5vHZzZd3QReITxsim+Lxee
3iVPI7sRPI6VYZFvtsG+sLJgQlUvrcD1pjkCUJDwIPQG8cnvmfUk8L1TtDOfeRZK
Uzn/NQgx8WNAcpOJtE3PrqDLRQl7jVHwulwXP+181RYSAeuX5z69qXZZ+7kq2lVh
OtTRKQbfed2VYdrd0emOizZH92zGNR8gtJ4PkCu3ThWEaYnH3eJ5r8FM/znoFOI1
P+rkllVce8AJ0+V+ZJOR3/hLQSN8bcOREm9shxWz7TixUPbkzsRUh4EAWamznyKL
ZUHQbv9MZZ5HEvw2+7Ukb8tULsXNBWm1mSMVMhE92XueTaavAkY6E1iPmWaZ1R7y
Tvmh1Gmq6Hk/DNb6qQtBPESKHGT9Y4T+8wbKDm8YilotwEZpQ0B1T7W/oTS+ZHKu
0woM7DnULdbtGaPcH1DM+3Q9XTkDWTbxVF3kG90f6oKezSpmntg=
=hlFt
-----END PGP SIGNATURE-----
4:42 a.m.
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.
Zdenek
5:16 a.m.
Dne 30. 06. 20 v 11:53 Vitaly Zaitsev via devel napsal(a):
On 30.06.2020 11:42, Zdenek Kabelac wrote:
> Default for unskilled users who may use lvm2 - should remain enabled.
If LVM was not used during installation => Anakonda can automatically
disable it.
Hmm - I don't think this is a good plan - it would be then different how the
package is installed.
The right plan is to fix all packaged dependencies and allow installation of
packages without lvm2.
If lvm2 is installed on system - it should have one 'default' installed
configation.
What you are proposing is - when user would deploy lvm2 DURING anaconda time
- it would behave the way A), but if user would just attach lvm2 storage
later one - it would behave in a way B).
So personally - the only way is to have fixed inter-package deps - and when
user does not want to have lvm2 on his system - he simply should not be
installing it - that's IMHO the correct solution here.
Zdenek
5:18 a.m.
New subject: Disabling lvm2-monitor.service (was Disable dmraid.service on
first run if no dmraid sets are found - Fedora 33 System-Wide Change
proposal)
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.
Regards,
Hans
5:27 a.m.
New subject: Disabling lvm2-monitor.service (was Disable dmraid.service on
first run if no dmraid sets are found - Fedora 33 System-Wide Change
proposal)
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)!
But problems need to be solved properly - not by 'ad-hock' hijacking correct
configuration.
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.
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.
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.
Zdenek.
5:43 a.m.
New subject: Disabling lvm2-monitor.service (was Disable dmraid.service on
first run if no dmraid sets are found - Fedora 33 System-Wide Change
proposal)
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
6:27 a.m.
New subject: Disabling lvm2-monitor.service (was Disable dmraid.service on
first run if no dmraid sets are found - Fedora 33 System-Wide Change
proposal)
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
7:08 a.m.
New subject: Disabling lvm2-monitor.service (was Disable dmraid.service on
first run if no dmraid sets are found - Fedora 33 System-Wide Change
proposal)
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
7:31 a.m.
New subject: Disabling lvm2-monitor.service (was Disable dmraid.service on
first run if no dmraid sets are found - Fedora 33 System-Wide Change
proposal)
Dne 30. 06. 20 v 14:08 Hans de Goede napsal(a):
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.
>
> 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. >
Well there can be some extras bit of settings tuned slightly better - but
overall I believe we do a pretty good here - service is automatically exiting
also when last user goes away for a longer period of time - so really
lvm2-monitoring as long as is not in-use shouldn't be bothering users.
For me lvm2-monitor.service quickly exits using just 34mS CPU time.
> 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).
It's probably still valuable to i.e. get notification in syslog about
full snapshot or thin-pool - so I'd say 34mS is reasonable compromise,
compared with the complexity we would have put on users to play with
services themself.
But it's good we came to conclusion lvm2-monitor service is not a problem ;)
Regards
Zdenek
3:29 a.m.
New subject: Disable dmraid.service on first run if no dmraid sets are found
- Fedora 33 System-Wide Change proposal
On Tue, Jun 30, 2020 at 11:04:26AM +0200, Zdenek Kabelac wrote:
Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a):
>On 29.06.2020 22:04, Ben Cotton wrote:
>>Fedora only support these RAID sets when they are already configured in
>>the BIOS at installation time. So we can solve the problem of
>>dmraid.service still depending on the obsolete udev-settle service by
>>making dmraid.service disable itself if no supported RAID sets are found
>>on its first run.
>
>+1 for this change.
>
>Also the LVM monitor can be disabled too if LVM is not used in current
>Fedora installation.
>
>LVM monitor: -2.01 seconds.
>RAID: -2.41 seconds.
If the user does not need lvm2, then the package should not be installed/
However when lvm2 is installed - lvm2 monitoring service is supposed to
be there and enabled - it should not impact load time all that much...
[The details have been discussed in some newer messages in the thread,
so I'm making just a general comment here:]
I don't think uninstalling packages or disabling services is the way
to go. Ideally, we should have packages for all frequently used
storage stacks installed by default, and all services required to
support such stacks also enabled by default when installed. Having
things "just work" by default makes the user experience vastly better.
We also shouldn't be lightly recommending masking or uninstalling of
packages because unexperienced users see such recommendations and may
follow them without fully understanding what the effect is.
Instead, services should be smart enough to exit quickly if they have
nothing to manage (which lvm2-monitor already does). And ideally,
storage services should only be started in response to hotplug events
that detect given hardware type to exist (which apparently could be
improved a bit, but as long as the noop cost is small, this is not a
such a big issue).
Zbyszek
3:45 a.m.
Dne 01. 07. 20 v 10:29 Zbigniew Jędrzejewski-Szmek napsal(a):
On Tue, Jun 30, 2020 at 11:04:26AM +0200, Zdenek Kabelac wrote:
> Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a):
>> On 29.06.2020 22:04, Ben Cotton wrote:
>>> Fedora only support these RAID sets when they are already configured in
>>> the BIOS at installation time. So we can solve the problem of
>>> dmraid.service still depending on the obsolete udev-settle service by
>>> making dmraid.service disable itself if no supported RAID sets are found
>>> on its first run.
>>
We also shouldn't be lightly recommending masking or uninstalling of
packages because unexperienced users see such recommendations and may
follow them without fully understanding what the effect is.
Instead, services should be smart enough to exit quickly if they have
nothing to manage (which lvm2-monitor already does). And ideally,
storage services should only be started in response to hotplug events
that detect given hardware type to exist (which apparently could be
improved a bit, but as long as the noop cost is small, this is not a
such a big issue).
Hi
And this is exactly what is our lvm2 service doing - it exits when it's being
idle for some tens of seconds.
Yep I also believe 'default' should just work in most configuration - even
when it's not always the top most optimal way to handle things.
Then skilled admins should be capable to set more optimal setups.
But I also believe making the lvm2 installation more 'optional' would be good
thing in making i.e. VM/container images actually smaller - as those often
do not need to have these tools & service installed at all - they just got a
single storage device to be on. But since currently lot of package now
get transient dependecy chains - lvm2 is often sucked-in even when
there is clearly no use for it at all.
So that's why having better 'package dependency' design matter - and the size
and efficiency still is important for some of us....
Zdenek
4:12 a.m.
New subject: Disable dmraid.service on first run if no dmraid sets are found
- Fedora 33 System-Wide Change proposal
On Mo, 29.06.20 16:04, Ben Cotton (bcotton(a)redhat.com) wrote:
https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun
== Summary ==
The Fedora workstation livecd is the default Fedora variant getfedora.org
advices people to download.
As such most Fedora workstation installs will be done from the livecd. This
means that any package which is part of the livecd will be part of the
default install for most users.
Dmraid is 1 of only 2 packages in the default install which still Requires
the long obsoleted systemd-udev-settle.service, which waits for all
device-detection to be done + some extra waiting just to be sure. This
significantly slows down booting on various systems.
Oh yes, please remove this. It's a shame that dmraid still requires
this, it's broken since 10 years to do this, and the maintainers know
it.
The dmraid people had ample time to fix their code. It's really time
this has to go.
Lennart
--
Lennart Poettering, Berlin
1401
days inactive
1403
days old
36 comments
14 participants
participants (14)
-
Alexander Ploumistos -
Ben Cotton -
Chris Murphy -
Hans de Goede -
Igor Raits -
John M. Harris Jr -
José Abílio Matos -
Lennart Poettering -
Michael Catanzaro -
Neal Gompa -
Samuel Sieb -
Vitaly Zaitsev -
Zbigniew Jędrzejewski-Szmek -
Zdenek Kabelac