I dischi SSD, Solid State Drive, stanno sempre prendendo piu’ piede sopratutto nei netbook ed ultrabook, ma ho gia’ visto dei server che montano questo tipo di disco.
A differenza degli Hard Disk classici non hanno parti in movimento quindi consumano molto meno, preservando la durata della batteria e sono infinitamente piu’ veloci nell’accesso ai dati e nel trasferimento.
Ha pero’ anche qualche difetto. Pur essendo resistente ai danni meccanici, ogni settore ha un numero di scritture limitato, ha un costo per gigabyte superiore agli hard disk e solitamente una dimensione minore. Fortunatamente sono parametri che stanno migliorando, gli SSD sono sempre piu’ resistenti alle scritture e sono meno costosi.
Adesso vediamo qualche ottimizzazione per usare questi devices nella maniera piu’ efficiente possibile.
TRIM
Prima di acquistare l’ssd dovremmo verificare che il disco supporti il comando TRIM, che comunica al controller dell’SSD quali blocchi sono inutilizzati e cancellando le celle direttamente in fase di cancellazione dei file, migliorando dunque le prestazioni.
Questo comando e’ supportato dai file system ext4, btrfs, JFS, e XFS.
Per verificare che il disco supporti TRIM diamo questo comando:
hdparm -I /dev/sda |grep TRIM # * Data Set Management TRIM supported (limit 1 block) # * Deterministic read data after TRIM |
L’opzione del file system che ci permette di utilizzare questo comando e’ discard. Possiamo passarlo come opzione in fstab o meglio utilizzare tune2fs per impostarlo tra i parametri di default.
tune2fs -o discard /dev/sdXY |
I/O scheduler
L’hard disk classico ha un braccetto che si muove sulla piastra del disco per raccogliere i dati. Possiamo pensare come ad un ascensore che va su e giu. Negli ascensori molto frequentati per richiamare l’ascensore ci sono due tasti: su e giu. Se l’ascensore sta scendendo e voi avete schiacciato il tasto giu si fermera’, se invece avete schiacciato su vi passera’ davanti e vi raccogliera’ al prossimo giro.
In maniera simile succede con lo scheduler dell’hard disk. Il kernel mette in coda le richieste, le riorganizza e raccoglie i dati in ordine, in modo da non far saltare il braccetto all’impazzata da una parte all’altra del piatto.
Con l’ssd non e’ necessario questo riordinamento, perche’ non c’e nessun braccetto da muovere, di contro la coda di ha un timeout di qualche millisecondo che ritarda il recupero dei dati.
La cosa migliore e’ quindi comunicare al kernel di non utilizzare nessuno scheduler per ogni disco ssd.
echo noop > /sys/block/sdX/queue/scheduler |
Questo comando non e’ persistente, al riavvio ricomincera’ ad utilizzare lo scheduler default.
Possiamo appoggiarci ad udev per impostare lo scheduler corretto quando viene rilevato l’hard disk.
Creiamo il file /etc/udev/rules.d60-schedulers.rules
# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sda", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop" |
swap
Usare lo swap sull’ssd vorrebbe dire veramente rovinarlo. Ma dopotutto se non possiamo farne a meno?
Per decidere se un dato debba andare su ram o su swap il kernel fa un calcolo con diversi parametri, tra cui un valore di swappines che di default e’ di 60. Infatti con il comando “free -m” vedrete che state utilizzando swap anche se la ram non e’ piena.
Per preservare la nostra SSD ed utilizzare la swap solo nel momento di assoluto bisogno impostiamo questo parametro a 1.
echo "vm.swappiness = 1" >> /etc/sysctl.conf sysctl -p /etc/sysctl.conf |
Access time
Ogni volta che facciamo un accesso ad un file o una directory sia in lettura che in scrittura viene aggiornato un valore di “access time” (atime). Questo valore viene utilizzato da alcuni programmi come mutt. Purtroppo pero’ questo continuo riscrivere l’atime porta a rovinare l’ssd. Solitamente si usa l’opzione di mount “noatime” che non aggiorna questo valore. Fortunatamente esiste un’altra opzione, meno conosciuta, che si chiama “relatime” che aggiorna il valore di atime solo se precedente all’ultima modifica, quindi non influisce troppo con il funzionamento di questi programmi.
/dev/sda1 / ext4 defaults,relatime 0 1 /dev/sda2 /home ext4 defaults,relatime 0 2 |
Usare tmpfs
tmpfs e’ un file system virtuale che utilizza un pezzo di ram come file system. Ovviamente allo spegnimento della macchina i files verranno persi, quindi dobbiamo utilizzarlo per file temporanei, tipicamente /tmp /var/tmp ed eventualmente una directory che utilizziamo per compilare.
In fstab impostiamo i punti di mount :
tmpfs /tmp tmpfs defaults 0 0 tmpfs /var/tmp tmpfs defaults 0 0 tmpfs /altro tmpfs defaults 0 0 |
Per i piu’ coraggiosi: disabilitiamo il Journaling
Il Journaling e’ una tecnica che da una parte aumenta l’affidabilita’ del disco, dall’altra aumenta il numero di scritture su disco.
Se ci fidiamo totalmente dell’alimentazione o meglio se utilizziamo sempre il portatile con la batteria collegata, possiamo azzardarci a disabilitare il journaling.
tune2fs -O ^has_journal /dev/sda1 |
Syslog via rete
Scrivere giga e giga di log su disco non fa granche’ bene alla nostra ssd. Se abbiamo la possibilita’ di utilizzare un syslog di rete, sara’ bene farlo. Per far cio’ dobbiamo andare a modificare il file /etc/rsyslog.conf commentando tutte le righe di questo tipo:
# *.info;mail.none;authpriv.none;cron.none /var/log/messages |
ed ora mandiamo tutto via riete e mostriamo tutte le righe di log sulla console 12
* @server *.error /var/tty12 |
quindi riavviamo il servizio:
systemctl restart rsyslog.service |
Btrfs
btrfs e’ il file system che sara’ utilizzato di default su RHEL7 (EDIT: La scelta di Red Hat per RHEL7 è stata XFS). Tra le altre cose interessanti, ha un’opzione di mount “ssd” che imposta alcune ottimizzazioni aggiuntive per le ssd. Attenzione che non abilita o disabilita l’opzione discard di cui abbiamo parlato prima.
Inoltre il wiki di btrfs ci avvisa che in alcuni casi l’opzione discard potrebbe peggiorare le prestazioni.
Possiamo usare quindi il comando fstrim in cron
echo "00 00 * * * root fstrim " > /etc/cron.d/fstrim |
