Fast Boot time on ArchLinux with SSD

Record boot times thanks to ArchLinux and a good SSD

I decided to write as my first article on InTheBit, some tricks on how to get satisfactions in boot times, as also recommended by many friends who often ask me for advice about it .. Well there is no magic, just some "secret" ...

We talk a lot about ArchLinux as a light and fast distribution, and in fact they say well!

Arch is designed for the elegance of the system, for the simplicity of management, and for its performance qualities.

The engine that allows the Linux kernel to run Arch so well is systemd, now many distributions are switching to systemd, but what makes Arch more powerful than the other distros?

Simple! The fact that the demons at the start we choose them, we will start only the bare essentials .. basically if we chose this distro we did it to create an environment optimized for everything for us.

I have a lot of fun with Arch, always modifying something, or trying out the latest news, and always with the fixation of having a record boot (I still have to find someone who really approaches me .. so the competition is open 😉)

This is my time:

Startup finished in 1.144s (kernel) + 568ms (userspace) = 1.713s

You say .. yes easy, you will not have anything in automatic start, but no! There is everything you need

133ms wicd.service
65ms nmbd.service
54ms systemd-timesyncd.service
45ms home.mount
30ms systemd-binfmt.service
29ms systemd-journald.service
24ms avahi-daemon.service
24ms systemd-logind.service
24ms systemd-vconsole-setup.service
18ms systemd-udevd.service
16ms sys-kernel-debug.mount
15ms systemd-remount-fs.service
15ms systemd-modules-load.service
14ms dev-mqueue.mount
11ms kmod-static-nodes.service
10ms systemd-udev-trigger.service
9ms dev-hugepages.mount
8ms tmp.mount
7ms user@1000.service
6ms systemd-tmpfiles-setup-dev.service
5ms var-tmp.mount
5ms systemd-sysctl.service
4ms var-log.mount
4ms systemd-random-seed.service
3ms systemd-journal-flush.service
3ms systemd-tmpfiles-setup.service
2ms systemd-update-utmp.service
2ms proc-sys-fs-binfmt_misc.mount
2ms alsa-restore.service
2ms sys-kernel-config.mount
1ms systemd-rfkill@rfkill0.service
1ms systemd-user-sessions.service
1ms systemd-backlight@backlight:acpi_video0.service
1ms sys-fs-fuse-connections.mount
1ms home-simoarch-.mozilla-firefox-default-Cache.mount

A second and seven!

Now I will briefly explain some tricks to get such times.

First we need a good SSD, I use a Crucial M550 from 128Gb, now they are at a price of around 50 cents per gigabyte, indeed they are cheaper than those from 256 Gb.

The second thing is the disk partitioning, I chose a GPT partitioning, but using my UEFI in legacy mode, (therefore using a somewhat different partitioning procedure to allow the correct functioning of the GPT table on BIOS or UEFI in mode legacy) as a filesystem I used BTRFS. (maybe in the future I'll write an article on the complete procedure)

BTRFS is a new concept filesystem, very powerful, and designed for solid state disks, offers multiple options of mount, and also has the ability to create snapshots of the filesystem, useful for having restorable backups of your system, or even your data.

However going back to the filesystem, I used these mount options in my file etc / fstab:

rw, noatime, ssd_spread, discard, compress = lzo, space_cache, inode_cache 0 0

The first option I added is noatime

It serves to prevent the updating of the inodes with the access time to the filesystem, useful therefore on solid state memories, moreover noatime is known to increase the performances. The default option used is relatime.

ssd_spread Includes various optimizations for solid state disks.

discard It serves to keep our dear SSD alive for a long time, ie it enables the benefits of the TRIM.

inode_cache New files are incrementally assigned to the inode.

space_cache It stores free space data to cache groups of blocks, it is an important option because it can increase performance, and it is also a good idea to use it if you are using new kernels.

compress=lzo This is my favorite, the LZO compression, much faster than the default ZLIB compression (I use LZO also as a compression of custom kernels instead of GLIB compression, if you wanted to try to compile the kernel with lzo compression, you must have installed the package lzop. Another high-performance compression (especially decompression) is LZ4, but due to too many commitments, I have not yet had a chance to try it 🙁 those wishing to know the pros of this algorithm follow the link of the project https://code.google.com/p/lz4/

Another interesting option to increase performance could be nodatacow "COW" is the copy on write technology used by BTRFS, nodatacow disables "security scripts" increasing overall performance.

I advise against disabling copy on write, for the possibility of losing important data or compromising them in the unfortunate event of a blackout or power outage, even if performance will increase.

With BTRFS it is not necessary to indicate the partitions that must undergo fsck, as you can see at the end of the string of mount options ho 0 0

Unlike other filesystems, the check with btrfs is done with the command

# btrfsck / dev / sdX

And you do it in case of problems, to recover the filesystem (unmountable root partition etc)

Another optimization for SSD is to change the default I / O scheduler which is CFQ with one suitable for solid state disks, it can be fine DEADLINE o NOOP

To do this we will have to edit the file

/ Etc / default / grub

And add to the kernel string the parameter

elevator = deadline

Or

elevator = noop

You will have to present it like this:

GRUB_CMDLINE_LINUX_DEFAULT = "quiet elevator = deadline"

once the system is restarted we will be able to check with this command

$ cat / sys / block / sda / queue / scheduler

That the scheduler is actually set deadline o noop.

Even having a custom kernel compiled by yourself helps to file a few tenths, to squeeze the maximum performance it is possible to use a localmodconfig to compile, and then maybe change something, how to remove the support initrd / initramfs, or use a different compression algorithm, as I mentioned earlier I use a LZO compression, which is significantly faster than the default compression. It must be said however that Arch itself is already very performing with its stock kernels "-ARCH", unlike the other distributions with Archlinux you will not notice big differences between a "homemade" kernel and the stock one.

Now a few suggestions about demons: I used a Display Manager for a long time, but when I started using this distro I asked myself a couple of questions .. like ..

I installed it in the hand and I chose what to install and how, could it possibly cause me some discomfort to log in as a user? The answer is obvious, and it's NO! A DM like KDM or GDM really takes away an eternity at boot time, there are also light solutions like LightDM or better SLIM, but in any case they negatively affect the start-up time, so for some time I decided not to install plus a display manager, but log in via text and start the graphical environment with "Xinit".
If you have KDE and you want to experience first-hand the performance improvement of this board, disable KDM (or your own DM in use). First let's check the current time

$ systemd-analyze blame

Then we disable the DM

# systemctl disable kdm.service

(To re-enable it, type: # systemctl enable kdm.service) On reboot after logging in from the console and starting with

startx

We check again with

$ systemd-analyze blame

systemd-analyze with the option blame allows us to check the time taken by each individual daemon, and therefore be able to act as much as possible. A random example is bluez, the bluetooth daemon: if it was installed and in automatic start, and we didn't want it or didn't always need it, it could be disabled; so also for the other services. Rather, in the case of programs used occasionally, I recommend starting them with systemctl at the time of use instead of keeping them enabled. To give another example, when I need to use teamviewer instead of always keeping it active, I start it manually with

# systemctl start teamviewerd.service

It is possible to have a graphical overview of the start time by exporting the result as a .svg image using the command

$ systemd-analyze plot> boottime.svg

In our home we will find a .svg image, by viewing it we will be able to read the times of the demons loaded by systemd, the demons that lose too much time will be highlighted in red.
I, who personally am lazy, have chosen to give an alias to the command startx, and I simply chose "X", in this way after logging in, I press x and send and I can work.
To assign an alias to startx you will need to edit the file ~/.bashrc o ~/.zshrcand add something like this:

alias x = 'startx'

It's comfortable for me "X" but everyone may prefer something else, as he may prefer to type startx in full.

Another interesting "gem" could be (and certainly is) an installation RAID0 always using solid state disks, and I plan to do it in the near future, money permitting.

Having said all this, I hope these tips will be useful to you, and if there was any doubt, ask for clarification in the comments

I reiterate that I do not recommend performing certain operations on systems used for work, or in any case systems that contain important data, I also remember that the possibility of losing data or having to re-run an installation is always around the corner, so these tips / tricks are destined exclusively for those people who like me in ArchLinux find a great fun, in breaking some records, and their own limits constantly improving.

Receive the latest posts by email

Enter the email and choose the inscriptions on the new page

InTheBit.it
Added devices
  • Compare Smartphone (0)
  • Compare Notebook (0)
Compare