Ottimizzare SSD sfruttando la RAM

[maddo]

Una piccola panoramica sulle configurazioni che ho usato per sfruttare la RAM e snellire il sistema. L'idea nasce come ottimizzazione per SSD, ma va bene in generale per ottenere velocità ove la RAM a disposizione sia abbondante rispetto alle normali necessità giornaliere.
Mi scuso per l'imprecisione, ma per semplicità chiamerò anche gli SSD "dischi", anche se non è corretto.
Comunque, è vero che i moderni SSD non sono fragili come un tempo, ma è altrettanto vero che il problema delle scritture non è risolto, è solo mitigato; ficcare cache varie e file temporanei nella memoria volatile si può dire che invece lo risolva alla radice, limitando il più possibile le scritture.
Anticipo che, in termini di sola velocità, le differenze sono marcate se avete il SO su un disco meccanico, mentre sono più contenute se lo avete su SSD - la velocità di lettura su SSD si avvicina a quella della RAM.
Chiudo la premessa ricordando che il file virtuale di sistema creato per sostenere il filesystem tmpfs viene dimensionato a circa il 50% della RAM totale. Quindi bisogna accertarsi che: (1) nell'uso normale, mediamente non si superi tale limite d'utilizzo; (2) sempre in via stimata, normalmente i file che andiamo a mettervi rimangano nella dimensione disponibile. Se non siete sicuri segnatevi i file che verranno nominati e andate a controllare (dopo qualche ora d'utilizzo) che dimensioni hanno raggiunto.

- SWAP -
La prima cosa, e questo vale ancora attualmente, quando si installa su SSD è NON prevedere una partizione di swap. Alternativamente, se pensate di usare ancora almeno un disco meccanico installato, la swap mettetela lì - preferibilmente in fondo al disco.

- FSTAB -
Le modifiche sostanziali si eseguono tutte sul file /etc/fstab
Le partizioni  - locate fisicamente su SDD - che dovete o volete montare all'avvio devono avere l'opzione 'noatime'. Volendo si può diminuire la frequenza di commit, di default è 5 secondi. Infine, come suggerito un po' ovunque, NON va usata l'opzione 'discard', che in teoria è nata per gli SSD ma riporta diversi bug; vedremo più avanti come sopperire al problema.
A titolo di esempio, la mia radice risulta montata così:

Codice Seleziona Espandi

# / was on /dev/sda3 during installation
UUID=xxxxxxx-xxxx-xxx-xxxxxx / ext4 noatime,commit=60,errors=remount-ro 0 1

Ed ora vediamo il succo di tutto il discorso: le directory temporanee. Andiamo a virtualizzare la cache di sistema, quella di apt (ed è quella che creerà qualche problema, più avanti risolto), i log di apt e la temporanea di sistema. Come suggerito in alcune guide, non toccherò invece la temporanea su 'var', in quanto in fase d'installazione alcune applicazioni la richiedono residente; in caso si fosse sicuri di non installare più nulla, si può mettere anche quella. Per me, non è una singola dir che cambia la vita, è molto più pratico lasciarla dov'è.
Ecco dunque le righe specifiche:

Codice Seleziona Espandi

# rammization
tmpfs /var/cache tmpfs noatime,defaults 0 0
tmpfs /var/cache/apt tmpfs noatime,mode=0755,defaults 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,relatime,mode=1777 0 0
tmpfs /var/log/apt tmpfs defaults,noatime 0 0
tmpfs /tmp/pouch tmpfs defaults,mode=1777,x-gvfs-show 0 0

Cos'è l'ultima riga?
Una directory che mi sono voluto riservare all'interno della ram come una sorta di tasca di scambio, un marsupio (pouch) nel quale andare a mettere file di scambio, file da modificare varie volte per poi venir scritti in modo permanente su SSD una sola volta - risparmiando così in un colpo solo in termini di velocità e consumo del disco.
L'opzione 'x-gvfs-show' permette al file manager grafico di visualizzarla alla stregua di un media montato all'avvio (tipo un DVD o un HD esterno, per intenderci), ed averla quindi disponibile per tutte le operazioni visuali. Una gran comodità, che richiede due attenzioni: (1) come detto prima, controllare sempre che le dimensioni di ciò che ci mettiamo siano contenibili in (meno del) 50% della ram; (2) ricordarsi che di fatto è una cartella volatile, non spegnere prima di aver salvato il contenuto che interessa!

- TRIM -
Non avendo usato l'opzione 'discard' è necessario ovviare manualmente. Per farlo esiste il comando 'fstrim', che dal kernel 5 (o forse già dal 4, non ricordo) viene richiamato automaticamente dagli SSD Samsung e Sandisk, con cadenza settimanale. Ora, il trimming del disco è di fatto un'operazione di scrittura e, come tale, è vero che va limitata; tuttavia il mancato trimming implica ben più numerose scritture, soprattutto con un uso intensivo del disco. Per farla breve, suggerisco che manualmente la cadenza sia giornaliera.
In pratica useremo le comode directory preimpostate di Cron. Anche perché scrivere una crontab è una punizione corporale  :bonk:
Nel mio script ho previsto anche la creazione di un log ed eventuali messaggi di errore. È solo un esempio, ovviamente ognuno lo può fare come vuole:

Codice Seleziona Espandi

# file log
TRIMLOG="/home/$USER/.trimlog"

# main
DAY=$(date +'%Y.%m.%d')
TOP=$( (fstrim -av) 2>&1 )
ES=$(echo $?)
if [[ "$ES" != "" ]]
then
TOP="$TOP\n > EXIT STATUS $ES"
fi
echo "\t$DAY\n$TOP" >> $TRIMLOG

# end
exit 0

Il punto cruciale è il comando 'fstrim -a' ("v" l'ho aggiunto in favore del log), che esegue il trimming su tutte le partizioni montate e residenti su dischi che permettono l'operazione.
Non si deve far altro che rendere eseguibile il file e sbatterlo in '/etc/cron.daily'

- SYNAPTIC -
A causa di un bug non risolto, Synaptic non riesce a creare un percorso funzionale ad "apt" quando le cartelle coinvolte sono in RAM. Trovato il percorso in questione - grazie a voi del forum - mi sono fatto un file di starting che lo fa in automatico.
Ho usato lo stesso script anche per risolvere un problema di permessi riguardo l'utente '_apt'.
Ecco dunque l'esempio che, come sopra, è modificabile alla bisogna:

Codice Seleziona Espandi

#!/bin/sh
### BEGIN INIT INFO
# Provides: inar
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Short-Description: INit Apt Rammization
# Description: crea file e cartelle nel file virtuale (resolve Synaptic bug)
### END INIT INFO

mkdir -p /var/cache/apt/archives/partial
chown -R _apt /var/cache/apt/archives/partial
touch /var/cache/apt/archives/lock
chmod 640 /var/cache/apt/archives/lock

exit 0

Si rende eseguibile il file, si mette in '/etc/init.d' e poi

Codice Seleziona Espandi

# update-rc.d -f nomescript defaults
Nel nostro caso deve eseguirsi all'avvio, quindi nei livelli 3 e 5 in particolare. Per verificare che l'operazione sia andata a buon fine, andate a vedere se nella dir '/etc/rc5.d/' esiste un file (link simbolico) con nome S01nomescript. Se c'è, ad ogni avvio si eseguirà.

Fatto, il sistema è pronto.
Per avere ancora un miglioramento che, vi assicuro, è determinante, si può virtualizzare anche la cache del browser - ma in modo più specifico, di molti altri programmi; il fatto è che ognuno conosce i suoi e quindi subentra la ricerca personale. Per rimanere sul generico, vediamo i due browser più comuni.

- CHROME -
Per Chrome/Chromium il sistema è meno elegante ma anche più semplice: bisogna aggiungere al lanciatore che lo esegue un parametro specifico. Dunque clikkate col tasto destro sul lanciatore che normalmente utilizzate (da menù, da barra di sistema, da dockbar, etc...) e nel comando scrivete:

Codice Seleziona Espandi

chrome-browser %U --disk-cache-dir=/vostra/dir
Va da sé che se usate Chromium il comando diventerà "chormium-browser", più il resto. Ed è anche ovvio che "/vostra/dir" dovrà essere scelta tra quelle virtualizzate, ad esempio '/var/cache'.
Come dicevo non è una soluzione elegante: se lanciate da terminale, o lo fa uno script, o cambiate il lanciatore, ecc... dovete avere l'accortezza di aggiungere sempre quel parametro.

- FIREFOX -
Per Firefox si fa dalle impostazioni avanzate interne. La menata è che ad ogni versione c'è sempre qualche voce che cambia... attualmente:
scrivere nella barra degli indirizzi "about:config"
confermare che siamo bravi e attenti
usare la barra di ricerca per trovare "browser.cache"
disabilitare ("false") la voce "browser.cache.disk.enable"
abilitare (se già non lo è) la voce "browser.cache.memory.enable" e renderla "true"
eventualmente settare la dimensione voluta, oppure "-1" per lasciare l'allocazione dinamica, alla voce "browser.cache.memory.capacity"

Questo è tutto. È molto meno impegnativo di quello che sembra, mi sono dilungato in chiacchere: una volta che si sa precisamente cosa fare, ci vogliono pochi minuti.
Poco tempo sacrificato per avere un sistema che può essere - da un po' a davvero - molto più scattante!

[Tony]

Ok.
Un unico appunto.
Volendo i comandi dello script per risolvere il problema di synaptic possono essere semplicemente messi solo nel file /etc/rc.local
Sempre creandolo se non c'è e dandogli i permessi di esecuzione.
Non servono altre modifiche o dare altri comandi.
P.S. Mi son permesso di rinominare il post, così è più specifico, credo.

[Piergiuseppegiorgio]

Una domanda, conviene mettere in etc/fstab

Codice Seleziona Espandi

UUID=xxxxxxx-xxxx-xxx-xxxxxx / ext4 noatime,commit=60,errors=remount-ro 0 1 commit=60?

[Tony]

Con commit si dice al sistema di sincronizzare i dati ed i metadati ogni tot secondi.
Il valore di default è di 5 secondi.
Se va via la corrente, si spegne forzatamente il pc, si perdono gli ultimi tot secondi di lavoro.
Quindi, più è alto il valore, meno spesso avviene tale sincronizzazione e meno spesso si va ad operare sul disco/ssd, con l'aumento del rischio di cui sopra.

[maddo]

Infatti, conta il nostro uso, la stabilità del nostro sistema, dell'hardware e della linea elettrica. Curiosando qua e là ho trovato valori suggeriti molto maggiori, io stesso in base alla valutazione di stabilità avrei potuto impstarlo tranquillamente a 10 volte tanto.
Tuttavia, ridurre di 12 volte è già un buon miglioramento, pur mantenendo un'ottima sicurezza; la valutazione finale è sempre soggettiva al caso specifico.

EDIT: mi sono dimenticato di scrivere che un'altra operazione spesso suggerita è quella di disabilitare il journaling. Sempre per valutazione svantaggi/benefici, pur avendo un sistema solitamente molto stabile, ritengo che disabilitare il journaling sia, detto chiaramente, una VACCATA.

Torniamo al discorso SSD moderni: le precauzioni in genere, come quelle qui descritte, ormai sono appunto -precauzioni- (migliorie se vogliamo), ma NON sono più passi obbligatori né tantomeno "salvavita". Di conseguenza, inutile e controproducente estremizzarle andando a minari (a volte anche di molto) integrità e stabilità generale.
Io stesso tutti questi cambiamenti li ho testati proprio per sincerarmi degli eventuali effetti negativi. Ne avessi avuti di evidenti, sarei immediatamente tornato indietro.

Secondo punto: il non-sense. Una delle forze dell'Ext4 è proprio il journaling, se lo togliamo tanto vale optare per un FS già senza. Eh ma, si legge in giro, per ora ext4 è quello che meglio si comporta sugli SSD. A parte che è tutto da verificare (migliorie notevoli sono state apportate in proposito anche su btrfs e su f2fs), ma allora se scegliamo il sistema che eglio si comporta è ancora più insensato andarlo poi a snaturare!

Tutto questo, come detto e come sempre, va poi valutato più profondamente caso per caso, ma in termini d'uso comuni e su sistemi comuni (desktop home-ufficio-programming-etc) valgono queste considerazioni :)

[Piergiuseppegiorgio]

Grazie, penso convenga quindi inserire commit=60. Posso approfittare per un'altra domanda a tema, a quali svantaggi si va incontro con un partizionamento MBR rispetto a GPT con l'SSD?

[maddo]

Non credo nessun svantaggio specifico, solo gli stessi che ci sono anche su HDD: non riconoscimento EFI, impossibilita di avere più di 4 partizioni primarie, dover (eventualmente) ricorrere alle estese, indicizzazione meno efficiente, ecc...

In definitiva, oggi come oggi, a meno di non usare hw davvero datato (e quindi non si può fare altrimenti), è abbastanza sconsigliabile ricorrere ancora al partizionamento MBR.
Tieni anche conto che è un lavoro che (almeno in teoria) effettui una sola volta per tanto tempo. Una volta impostata la tabella partizioni di un certo tipo, queste si possono poi piazzare e ridimensionare anche varie volte, ma la struttura base rimane quella.
Non succede tutti i giorni (e spero nemmeno tutti i mesi) di rivoluzionare completamente un partizionamento; soprattutto, non deve succedere su un SSD (sempre il solito discorso scritture-riallocazioni, etc...)
;)

[Piergiuseppegiorgio]

Grazie, sapresti anche dirmi le differenze relative al numero di scritture?

[maddo]

Non ho capito la domanda. Se intendi tra MBR e GPT, sinceramente non so se ci sia una significativa differenza. Ad intuito, comunque, al di là del numeretto mi verrebbe da pensare che essendo GPT un sistema molto più nuovo, abbia pensato anche alle tecnologie flash in modo specifico, a differenza di MBR (che sicuramente non ha alcuna ottimizzazione al riguardo).
Ma ripeto, è solo un'ipotesi intuitiva.

[Piergiuseppegiorgio]

Grazie del parere, vedi il mio dubbio e' questo, ho montato SSD Kingston in pc con bios, con partizionamento MBR (l'installer di mint non mi ha proposto GPT per cui ho dedotto che il  bios non lo supportasse). Ora mi viene il dubbio che forse avrei fatto meglio ad usare il partizionamento GPT.

[nessuno]

In una vecchia guida per gli SSD avevo letto che il partizionamento MBR fosse deprecato a favore di quello GPT, adesso non so se quell'indicazione fosse valida all'epoca e  invece attualmente non lo sia più, perché magari è stata superata da una evoluzione dei sistemi  sia hardware che software. Nel dubbio continuo a utilizzare il GPT sugli SSD e il MBR sugli HDD, utilizzando gli HDD per l'avvio dei sistemi su SSD.
La domanda però me la sono posta anch'io: Il partizionamento MBR è deprecato sugli SSD oppure no? E' una vecchia indicazione di cui non tenere più conto oppure no?

A me sembra ci sia tanta gente che il problema non se lo è posto e usa il MBR sugli SSD,  non mi sembra si stiano lamentando ...  Boh! :ciao:

[maddo]

Come detto, gli SSD moderni riparano a molte mancanze di sistemi vecchi, come il partizionamento MBR o il filesystem NTFS (che con la sua frammentazione e l'indicizzazione inefficiente era devastante sui primi SSD).
Quindi è normale che si possano usare e chi lo fa "non se ne lamenti".

Il punto è: cosa si può fare o cosa è -meglio- fare?
Indubbiamente è meglio usare GPT (come dicevo sopra, e un istema che ha scheduling specifici per le nuove memorie flash) e filesystem che non presentano frammentazione. Ma non è che altrimenti ti esplode il disco o ti cala l'accetta in testa :)

Se il bios è vecchio potrebbe non supportare ancora GPT, quindi ci sta tutto che hai usato ancora MBR. Se è un sistema casalingo ad uso privato, senza troppe fisime, non c'è bisogno che rifai tutto solo per cambiare il partizionamento.
Tienilo però a mente e, la prossima volta che dovessi cambiare motherboard, o rivoluzionare il disco, approfittane ed usa GPT.