Fast Boot time su ArchLinux con SSD

Tempi di boot da record grazie ad ArchLinux ed un buon SSD

Ho deciso di scrivere come mio primo articolo su InTheBit, qualche trick sul come ottenere soddisfazioni nei tempi di boot, come anche consigliato da molti amici che spesso mi chiedono consigli a riguardo.. Bene non c’è nessuna magia, solo qualche “segreto”…

Si parla tanto di ArchLinux come una distribuzione leggera e veloce, ed in effetti dicono bene!

Arch è disegnata per l’eleganza del sistema, per la semplicità di gestione, e per le sue doti di performance.

Il motore che permette al kernel Linux di far andare così bene Arch è systemd, ormai molte distribuzioni stanno passando a systemd, ma cosa rende Arch più performante delle altre distro?

Semplice! Il fatto che i demoni all’avvio li scegliamo noi, faremo partire solo lo stretto necessario.. in fondo se abbiamo scelto questa distro lo abbiamo fatto per crearci un ambiente ottimizzato in tutto e per tutto per noi.

Io con Arch mi diverto un sacco, sempre a modificare qualcosa, o provare le ultime novità, e sempre con la fissa di avere un boot da record (devo ancora trovare qualcuno che mi si avvicini realmente.. quindi la competizione è aperta )

Questo è il mio tempo:

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

Direte voi.. sì facile, non avrai nulla in avvio automatico, invece no! C’è tutto ciò che serve

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

Un secondo e sette!

Ora spiegherò brevemente qualche trick per ottenere dei tempi del genere.

Per prima cosa abbiamo bisogno di un buon SSD, io uso un Crucial M550 da 128Gb, ormai si trovano ad un prezzo di circa 50 centesimi a gigabyte, anzi sono più convenienti quelli da 256 Gb.

La seconda cosa è il partizionamento del disco, io ho scelto un partizionamento GPT, usando però il mio UEFI in legacy mode, (perciò usando una procedura di partizionamento un po’ diversa per permettere il corretto funzionamento della tabella GPT su BIOS o UEFI in modalità legacy) come filesystem ho usato BTRFS. (magari in futuro scriverò un articolo sulla procedura completa)

BTRFS è un filesystem di nuova concezione, molto performante, e studiato per i dischi a stato solido, offre molteplici opzioni di mount, ed inoltre possiede la capacità di creare degli snapshot del filesystem, utilissimi per avere dei backup ripristinabili del proprio sistema, o anche dei propri dati.

Comunque tornando al filesystem, ho usato queste opzioni di mount nel mio file etc/fstab:

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

La prima opzione che ho aggiunto è noatime

Essa serve a prevenire l’aggiornamento degli inode con i tempi d’accesso al filesystem, utile quindi su memorie a stato solido, inoltre noatime è conosciuta per aumentare le prestazioni. L’opzione di default usata è relatime.

ssd_spread Include varie ottimizzazioni per i dischi a stato solido.

discard Serve a tenere in vita a lungo il nostro caro SSD, cioè abilita i benefici del TRIM.

inode_cache I nuovi file vengono assegnati all’ inode in modo incrementale.

space_cache Memorizza i dati di spazio libero per fare cache su gruppi di blocchi, è un opzione importante perché può aumentare le prestazioni, inoltre è buona norma utilizzarla nel caso si usino kernel non proprio recenti.

compress=lzo Questa è la mia preferita, la compressione LZO, molto più veloce della compressione ZLIB di default (uso LZO anche come compressione dei custom kernel anzichè la compressione GLIB, se si volesse provare a compilare il kernel con compressione lzo, bisogna aver installato il pachetto lzop. Un’altra compressione molto performante (sopratutto la decompressione) è LZ4, ma a causa dei troppi impegni, non ho ancora avuto modo di provarla chi volesse conoscere i pro di questo algoritrmo segua il link del proggetto https://code.google.com/p/lz4/

Altra opzione interessante per aumentare le prestazioni potrebbe essere nodatacow “COW” è la tecnologia di copy on write utilizzata da BTRFS, nodatacow disabilita le “scritture di sicurezza” aumentando le prestazioni in generale.

Sconsiglio di disabilitare il copy on write, per la possibilità di perdere dati importanti o comprometterli nel malaugurato caso di un black-out o di un interruzione di corrente, anche se aumenterà le performance.

Con BTRFS non serve indicare le partizioni che devono subire il fsck, come si può notare alla fine della stringa delle opzioni di mount ho 0 0

A differenza di altri filesystem il check con btrfs si fa con il comando

# btrfsck /dev/sdX

E lo si fa in caso di problemi, per recuperare il filesystem (partizione di root non montabile ecc)

Altra ottimizzazione per SSD è cambiare lo scheduler I/O di default che è CFQ con uno adatto ai dischi a stato solido, può andare bene DEADLINE o NOOP

Per farlo dovremo editare il file

/etc/default/grub

Ed aggiungere alla stringa del kernel il parametro

elevator=deadline

Oppure

elevator=noop

Si dovrà presentare così:

GRUB_CMDLINE_LINUX_DEFAULT="quiet elevator=deadline"

una volta riavviato il sistema potremo controllare con questo comando

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

Che lo scheduler impostato sia effettivamente deadline o noop.

Anche avere un custom kernel compilato da sé aiuta a limare qualche decimo, per spremere al massimo le prestazioni è possibile usare una localmodconfig per compilare, e poi magari cambiare qualche cosa, come togliere il supporto initrd/initramfs, o usare un diverso algoritmo di compressione, come ho già accennato uso una compressione LZO, che è significativamente più veloce della compressione di default. C’è da dire però che Arch di per sé è già molto performante con i suoi kernel stock “–ARCH”, a differenza delle altre distribuzioni con Archlinux non si noteranno grandi differenze tra un kernel “fatto in casa” e quello stock.

Ora qualche suggerimento riguardo ai demoni: ho usato per molto tempo un Display Manager, ma quando ho incominciato ad usare questa distro mi sono fatto un paio di domande.. del tipo..

L’ho installata a manina ed ho scelto cosa installare e come, potrà forse crearmi qualche fastidio eseguire il login utente da console? La risposta è scontata, ed è NO! Un DM come KDM o GDM porta via davvero un eternità al tempo di boot, esistono anche soluzioni light come LightDM o meglio SLIM, ma in ogni caso incidono negativamente sul tempo d’avvio, perciò da un po’ di tempo ho deciso di non installare più un display manager, ma loggarmi via testuale ed avviare l’ambiente grafico con “xinit”.
Nel caso si avesse KDE e si volesse tastare con mano il miglioramento prestazionale di questo consiglio, disabilitare KDM (o il proprio DM in uso). Per prima cosa controlliamo il tempo attuale

$ systemd-analyze blame

Poi disabilitiamo il DM

# systemctl disable kdm.service

( Per riabilitarlo digitare: # systemctl enable kdm.service) Al riavvio dopo esserci loggati da console ed aver avviato con

startx

Controlliamo nuovamente con

$ systemd-analyze blame

systemd-analyze con l’opzione blame ci permette di controllare il tempo impiegato da ogni singolo demone, e quindi poter agire per quanto possibile. Un esempio a caso è bluez, il demone del bluetooth: nel caso fosse installato ed in avvio automatico, e non lo volessimo o non ci servisse sempre, si potrebbe disattivarlo; così anche per gli altri servizi. Consiglio piuttosto, nel caso di programmi usati saltuariamente di avviarli con systemctl al momento dell’utilizzo invece che tenerli abilitati. Per fare un altro esempio, quando ho la necessità di usare teamviewer invece che tenerlo sempre attivo, lo avvio manualmente con

# systemctl start teamviewerd.service

È possibile avere una panoramica grafica del tempo d’avvio esportando il risultato come immagine .svg mediante il comando

$ systemd-analyze plot > boottime.svg

Nella nostra home troveremo un immagine .svg, visualizzandola potremo leggere i tempi dei demoni caricati da systemd, i demoni che perdono troppo tempo saranno evidenziati in rosso.
Io che personalmente a volte sono pigro, ho scelto di dare un alias al comando startx, ed ho scelto semplicemente “x”, in questo modo dopo aver effettuato il login, premo x ed invio e posso lavorare.
Per assegnare un alias a startx bisognerà editare il file ~/.bashrc o ~/.zshrced aggiungere qualcosa del genere:

alias x='startx'

Per me è comodo “x” ma ognuno può preferire qualcos’altro, come può preferire digitare startx per intero.

Un altra “chicca” interessante potrebbe essere (e sicuramente lo è) un’installazione RAID0 sempre usando dischi a stato solido, ed ho in previsione di farlo nel prossimo futuro, soldi permettendo.

Detto tutto ciò spero che questi consigli possano tornarvi utili, e in caso ci fosse qualche dubbio chiedete chiarimenti nei commenti

Ribadisco che sconsiglio di eseguire certe operazioni su sistemi usati per lavoro, o comunque sistemi che contengano dati importanti, ricordo pure che la possibilità di perdita dei dati o di dover rieffettuare un’installazione è sempre dietro l’angolo, quindi questi suggerimenti/tricks sono destinati esclusivamente a quelle persone che come me in ArchLinux trovano un grande divertimento, nel battere qualche record, ed i propri limiti migliorandosi in continuazione.

Il post Fast Boot time su ArchLinux con SSD è stato pubblicato su InTheBit - Il Blog sulla Tecnologia che alimenta le tue passioni!.