Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux