Systemd-udev-settle.service deprecated, biggest contributor to boot time

[Mr_Magoo]

https://www.man7.org/linux/man-pages/man8/systemd-udev-settle.service.8.html

Using this service is not recommended. There can be no guarantee that hardware is fully discovered at any specific time, because the kernel does hardware detection asynchronously, and certain buses and devices take a very long time to become ready, and also additional hardware may be plugged in at any time. Instead, services should subscribe to udev events and react to any new hardware as it is discovered. Services that, based on configuration, expect certain devices to appear, may warn or report failure after a timeout. This timeout should be tailored to the hardware type. Waiting for systemd-udev-settle.service usually slows boot significantly, because it means waiting for all unrelated events too.

/lib/systemd/system/zfs-mount.service shows:
After=systemd-udev-settle.service

Is there a workaround such that ZFS will still work, but we can systemctl mask systemd-udev-settle.service? On my system, it is the biggest contributor to boot time at 4.377 seconds.

sudo systemd-analyze blame
4.377s systemd-udev-settle.service

Or has systemd-udev-settle.service been updated and is no longer deprecated?

[Aravisian]

Here is a rather lengthy process of elimination another user went through:

Slow booting: systemd-udev-settle.service

While configuring and tweaking your machine can be entertaining as well as providing opportunities for learning and growth, it is also important to remember that Boot Takes Time. It is the initialization of the entire system. It amazes me that booting up Zorin OS can often take less time than launching some particular single applications.

Your efforts can be encouraged, but with a sticky note stuck to your forehead bearing the reminder that under 10 seconds of boot time is not critical and that explorations are done for educational purposes.

And users getting rather fanatical about reducing boot time can also cause some lasting or difficult to reverse consequences.
One very common one is setting the default grub file GRUB_TIMEOUT value to zero... which seems fine, except that when they need to access the Recovery Menu, they are utterly unable to do so. Which is a massive frustration when Recovery Menu is needed.