SSD optimization (42.2 RC2) - any good?

Hallo, in my new pc with my first SSD, I have followed this guide short after having 42.2 RC2 installed:

The startup was ultra-fast before, but now is about 35s. The splash-screen with the 3 moving green dots have appeared and takes several seconds, while the first part of the boot is still fast.

This is systemd-analyze:

Startup finished in 6.562s (firmware) + 3.526s (loader) + 1.990s (kernel) + 1.994s (initrd) + 20.924s (userspace) = 34.998s @20.863s
└─display-manager.service @20.243s +619ms
  └─ @20.228s
    └─ntpd.service @19.667s +561ms
      └─ @19.551s
        └─wicked.service @1.524s +18.026s
          └─wickedd-nanny.service @1.507s +14ms
            └─wickedd.service @1.495s +9ms
              └─wickedd-dhcp6.service @1.410s +39ms
                └─SuSEfirewall2_init.service @940ms +425ms
                  └─ @824ms
                    └─ @824ms
                      └─iscsid.socket @824ms
                        └─ @824ms
                          └─apparmor.service @219ms +604ms

I wonder If you experts trust this guide and, in case, if there is something I can do to improve the boot timing.

So do you need ipv6? If not disable via YaST Network settings, so nntpd and your network are taking the longest, investigate tweaks there…

I remove plymouth, lock the 10 or so packages and rebuild initrd (mkinitrd).

Hallo Malcolm,
thanks, you are years ahead of me, I’m afraid I have to dig a lot to understand what I have to do…

No idea where to start with nntpd. Anyway, with yast I disabled ipv6 and wicked service. Is it a good idea?
Here is the result, not bad:

Startup finished in 6.562s (firmware) + 2.516s (loader) + 1.992s (kernel) + 1.741s (initrd) + 12.013s (userspace) = 24.826s @11.976s
└─ @11.976s
  └─smb.service @11.814s +161ms
    └─nmb.service @1.431s +10.334s
      └─ @1.414s
        └─wpa_supplicant.service @5.960s +22ms
          └─ @888ms
            └─ @888ms
              └─avahi-daemon.socket @888ms
                └─ @888ms
                  └─sys-fs-fuse-connections.mount @4.258s +12ms
                    └─systemd-modules-load.service @215ms +7ms

…but is the firewall still there?

So, your booting a desktop and using NetworkManager? Do you need the samba services running?

The ntp service is the network time daemon, do you want/need this?

No SuSE Firewall there, again do you need this?

So this is still the RC version or the released version?

yes, I need samba. I have disabled ntp and enabled the firewall but it does not appear in the chain.

I’m going to update to the 42.2 asap.
Today I have update a quad-core with a WD-Black, realizing that its boot is a bit faster than this one with SSD. I’m afraid there is something wrong.


Startup finished in 6.541s (firmware) + 9.810s (loader) + 1.988s (kernel) + 1.729s (initrd) + 11.850s (userspace) = 31.920s @11.818s
└─ @11.818s
  └─smb.service @11.674s +143ms
    └─nmb.service @1.222s +10.440s
      └─ @1.186s
        └─wpa_supplicant.service @5.593s +58ms
          └─ @889ms
            └─ @889ms
              └─avahi-daemon.socket @889ms
                └─ @889ms
                  └─sys-fs-fuse-connections.mount @3.950s +3ms
                    └─systemd-modules-load.service @266ms +9ms

systemd-analyze blame
         10.440s nmb.service
          2.732s rc-local.service
          2.609s fstrim.service
          1.179s postfix.service

So you need to look at the journal and status of the nmb service to see why it takes 10 seconds…

journalctl --boot --unit=nmb.service
systemctl status nmb.service

Some services are a one off eg fstrim, purge-kernels etc so that can change times for a particular boot…

[QUOTE=DOSshell;2800598]Hallo, in my new pc with my first SSD, I have followed this guide short after having 42.2 RC2 installed:


I’ve talked about these so called tips to Greg KH ( kernel maintainer ) in the past. According to him there’s no need for such tweaking, it rather might influence performance in the long run. One of the reasons given for the tweaks is the wearing of the SSD. Real tests have proven that the danger only exists if huge amounts of data get (re)writen continuously over a period of years.

Another thing: I also talked to the guy who maintains the tips and tricks site, to provide support on the tips and tricks, which he refused.


From my own experience using that guide, I have seen significant slow downs when trying to TRIM at boot. It was really annoying. whenever I feel like performing the TRIM function I just do it manually. It is way faster!

My 2 cents…:wink:

Here is the outputs as per Malcolm suggestion - this is Chinese, for me:

journalctl --boot --unit=nmb.service
Hint: You are currently not seeing messages from other users and the system.
      Users in the 'systemd-journal' group can see all messages. Pass -q to
      turn off this notice.
-- No entries --

systemctl status nmb.service
● nmb.service - Samba NMB Daemon
   Loaded: loaded (/usr/lib/systemd/system/nmb.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2016-11-21 19:01:48 CET; 2h 50min ago
 Main PID: 1212 (nmbd)
   Status: "nmbd: ready to serve connections..."
    Tasks: 1 (limit: 512)
   CGroup: /system.slice/nmb.service
           └─1212 /usr/sbin/nmbd -D

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Knurpht and Cuttlefish, thanks for sharing the Interesting opinions/experience about the optimization.
I’ve read more here and here and I’m more confused.

I’m seriously wondering if it’s worth reinstall 42.2 and stick to the official tips here:

If you use BTRFS there is little that needs to be done most of those suggestion are for EXT4 or other file systems.My advise is to just use the default and worry about optimizing latter. Also most are for ware not speed and modern SSD can sustain terra byte daily writes for years. There are a few that deal with speed but the difference would not be noticed by a human

OK, try;

journalctl -b --no-pager | grep nmb

Try a reboot and see if it still shows a delay for nmb. Are you using NetworkManager or Wicked?

FWIW, most optimizations are covered these days, the only thing I do with SSD’s is tweak the swappiness in /etc/sysctl.conf.

# Disable swap
vm.swappiness = 1
vm.vfs_cache_pressure = 50