I bought a SSD hoping it would speed up my system boot time but tit did not after I resized my data partitions on the SSD that come after the system partitions. When I first Cloned my 72000 RPM 1TB drive to my new 1TB SSD it was much faster but then when I used the slightly extra space on the drive for a NTFS Data partition and recreated another Swap partition it stopped being faster and actually took longer by 7 seconds to boot compared to booting from the hard drive. What is the point of the expensive SSD if it does not speed up my system boot time? Might as well have just stuck with the regular hard drive that will last longer than a SSD.
I created a NTFS Data Partition and a Swap Partition in the unused space of the SSD and the NTFS partition is empty right now so it's not at all close to being full. I cloned my 1TB Hard Drive but the SSD is slightly larger so I wanted to use it's extra space.
Windows 10 boots faster so it's not a too full SSD problem. The System Partition is EXT4 and only35 percent full.
When I do a Benchmark Disk option with the Disks Program it gets 497.9 MB/s with access time of 0.27 msec.So it's defiantly performing much faster than a hard drive.
You can run systemd-analyze to get some info.
I added an SSD (/dev/sdb) to this PC (a basic one, see the specs bellow) and got a 6x boot-up speed time.
Note that I update this system by running a script and disabled daily updates from the system because sometimes this could delay the boot for about a minute.
On my Linux System ext4 partition out of 184 GB 65 GB is used and 119 GB is free so it's only 36% Full.
I also have a 72 GB NTFS Partition for Data storage to share between Linux and Windows 10 and a 8 GB Swap partition that is at the end of the drive for ease of changing the size of my Linus System partition and NTFS Data partition.
Is a Swap Partition really necessary or is it better to have a Swap file if there is such a thing? It seems after I messed with the Swap and NTFS partitions, the boot time increased. Before adding the NTFS and Swap partitions my system booted up almost instantly and that Ubuntu Animated dots screen did not even complete one full animation before the desktop came up, now it will take more than 10 animations before the desktop comes up.
I guess it probably will take a long time, depending on the size of the partition being changed. I guess it will essentially have to rewrite the entire partition.
The fstrim -v / seemed to have done the trick, now my Desktop come up in 16 seconds from hitting Enter to load Linux from the Boot Manager.
Lets hope it stays that way.
The service is enabled by default, so that it should not happen again.
Check that this is the case:
~
âžś systemctl status fstrim.service
â—Ź fstrim.service - Discard unused blocks
Loaded: loaded (/lib/systemd/system/fstrim.service; static; vendor preset: enabled)
Active: inactive (dead) since Wed 2019-06-05 09:02:48 CEST; 1min 6s ago
Process: 2046 ExecStart=/sbin/fstrim -av (code=exited, status=0/SUCCESS)
Main PID: 2046 (code=exited, status=0/SUCCESS)
If it's not enabled for some reason, do systemctl enable fstrim and systemctl start fstrim.
Maybe, you are using the disk a lot and moving big files.
In that case, the default timer (fstrim runs periodically) may not be adapted.
Create a /etc/systemd/system/fstrim.timer file that will supersede the default one:
[Unit]
Description=Discard unused blocks once a day
Documentation=man:fstrim
[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true
RandomizedDelaySec=30m
[Install]
WantedBy=timers.target
Above, I am running it daily instead of weekly.
Again, enable it (enable/start) and make sure it's running:
âžś systemctl status fstrim.timer
â—Ź fstrim.timer - Discard unused blocks once a day
Loaded: loaded (/etc/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Fri 2019-05-31 14:31:16 CEST; 4 days ago
Trigger: Thu 2019-06-06 00:13:53 CEST; 15h left
Docs: man:fstrim
I just checked this on my own machine and found fstrim not bein active. systemctl start fstrim does work, yet systemctl enable fstrim shows this message:
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified.
There is no solution because there is no problem.
This systems unit does not need to be enabled, it is not a service but a timer.
I made a mistake at first, let's stop about it.