Sostituire un HD con un SSD

In questi giorni, grazie ad un prezioso regalo, sono riuscito ad avere un SSD  Samsung series 840 da 120 GB. Questo gioiellino ha sostituito, nel mio DELL Inspiron 6400, il precedente disco da 160GB (un WD Scorpio 5400 RPM da 160GB).

Samsung SSD Series 840 160 GB

La perdita nominale di 40 GB non si è per nulla avvertita, anzi! Poiché sul nuovo disco non ho riportato dall'HD precedente, la partizione Windows XP, un paio di partizioni DELL per recovery e test (piccole) e la partizione DELL MediaDirect (funzionalità praticamente mai usata), sono riuscito anche a guadagnare una decina di GB!
Dopo aver dato un occhiata in giro per avere notizie sull'uso di un SSD al posto di un HD classico, mi sono dato da fare.
La prima cosa da fare è stato scegliere come migrare i dati. 

Partizionare l'SSD

Le partizioni, giocoforza, dovevano essere di grandezza maggiore od uguale a quelle preesistenti su HD, anche se in posizioni differenti, e non avrei potuto dividere una partizione già presente in due o più parti (almeno non in questa fase, ma mi sono ripromesso di crearne una separata per /var prossimamente).
Come tabella delle partizioni ho scelto msdos (vecchia ma sempre buona), poiché  più di quattro partizioni (primarie, per sovrammercato!) al momento non mi sarebbero servite (niente partizioni estese), inoltre non avevo voglia di perder tempo studiare GPT o meglio ancora LLVM (stiamo sempre parlando di un notebook con solo un disco interno, diamine!).

Ecco quindi ripartito così il disco:

Modello: ATA Samsung SSD 840 (scsi)
Disco /dev/sda: 120GB
Dimensione del settore (logica/fisica): 512B/512B
Tabella delle partizioni: msdos
Flag del disco:

Numero  Inizio  Fine    Dimensione  Tipo     File system     Flag
 1      1049kB  42,9GB  42,9GB      primary  ext4            avvio
 2      42,9GB  116GB   72,8GB      primary  ext3
 3      116GB   120GB   4296MB      primary  linux-swap(v1)

Tutte le partizioni sono allineate al megabyte, come da più parti suggerito (sia per facilitare al firmware la lettura/scrittura, sia perché LBA e CHS non hanno più senso negli SSD, secondo me).
La prima partizione (quella di avvio) è dedicata al filesystem di root, la seconda al filesystem /home e la terza ed ultima (per ora) è dedicata per lo swap (ricordo che questo è l'unico disco su questo portatile e dello swap ne parleremo ancora in seguito). Le partizioni sono state formattate con gli stessi filesystem esistenti sul vecchio HD, visto che i dati sarebbero stati clonati con un qualche tool. Inoltre, ho previsto uno spazio di swap di 4GB, sebbene attualmente il sistema ospiti 2GB di RAM, in vista di una futura espansione della RAM (nonostante quanto dica DELL sembra che sia possibile espanderla fino ad un max di 3GB).

Migrare i dati.

Per questo passaggio ho scelto di utilizzare una distribuzione live che contenesse qualche utility più o meno preconfezionata per la copia delle partizioni (non ho più molto tempo libero ormai, l'ho già detto? ;-). Ho così utilizzato Clonezilla, avviabile da chiavetta USB, con interfaccia a caratteri a due modalità (esperto e novizio), basata sul classico dd.
Ho trasferito il sistema utilizzando la modalità novizio, ovviamente sapendo che avrei dovuto ripristinare il Master Boot Record e quanto altro prima di avere un sistema funzionante.

Rispristino di MBR con grub

Provo un riavvio senza ripristinare Grub2, per vedere l'effetto che fa, ed ovviamente il sistema non parte. Prima di ripristinare il boot record faccio una controllatina in /etc/fstab , credendo di dover ripristinare i corretti UUID per le partizioni, ma magia! il file conteneva i dati corretti per tutte le partizioni! Sospetto che a mettere a posto il file sia stato Clonezilla, ma potrei sbagliarmi. Purtroppo, da cattivo sys-admin (diavolo, sono pur sempre un developer!), non ho tenuto un log delle operazioni effettuate e la memoria adesso potrebbe farmi brutti scherzi, ma sono abbastanza certo della sorpresa ne trovare fstab corretto, dato che mi ero appuntato i valori precedenti ed avevo estratto i nuovi valori con blkid.
Ripresomi dalla sorpresa, ho usato una vecchia live Sabayon (la 8, per la precisione, visto che le successive, da perfetta distro rolling, non mi sono mai servite :-P)  per ricreare grub2.

Il tuning.

Avviato il sistema, tutto è ripartito come se nulla fosse cambiato (a parte una maggiore velocità al boot ed una reattività maggiore. Come ci si aspettava, d'altronde!).
Eccomi proto, quinti ad affrontare il tuning del sistema.
Non potendo trasferire la swap area su HD, né disabilitarla, ho diminuito il valore della swappiness, come suggerito da alcuni. Per farlo in modo permanente, ho creato il file /etc/sysctl.d/SSD_no_swap.conf dal seguente contenuto:

# for SSD drives swappiness must be 0 or 1!
# see http://mynixworld.wordpress.com/2011/11/17/gentoo-before-and-after-ssd/
# or http://apcmag.com/how-to-maximise-ssd-performance-with-linux.htm
# TuxmAL 22/06/2013
vm.swappiness = 1

Poiché si suggeriva anche di modificare lo scheduler dei processi, in quanto   CFQ potrebbe non essere più all'altezza dei compit,i fidando troppo in una latenza dell'I/O ora non più presente, ho deciso di provare NOOP.
Per rendere permanente il cambiamento, ho creato il file /etc/local.d/SSD_pref_scheduler.start dal seguente contenuto:

# for SSD drives nest scheduler is NOOP scheduler.
# see http://mynixworld.wordpress.com/2011/11/17/gentoo-before-and-after-ssd/
# or http://en.wikipedia.org/wiki/Noop_scheduler
# or http://apcmag.com/how-to-maximise-ssd-performance-with-linux.htm
# TuxmAL 22/06/2013
echo noop > /sys/block/sda/queue/scheduler

Tutto qui!

Conclusioni

Sono molto contento della maggiore responsività del sistema e della maggior velocità dell'I/O, ma non son sicuro che il nuovo scheduler sia veramente migliore di quello standard (CFQ). Spero di poter fare qualche prova qualitativa al più presto, per cercare la soluzione più soddisfacente. Nel frattempo, cercherò di acquistare un altro po' di RAM per cercare di rendere più  veloce la mia linux box (3Gb è meglio di 2Gb).

Aggiornamento!

Proprio quando tutto sembrava a posto, mi sono accorto che al boot veniva segnalata (con un messaggio non bloccante) una partizione inesistente. Visto che GRUB2 non c'entrava nulla (dopo averlo comunque ricontrollato e rigenerato per sicurezza), ho indagato un po' meglio. Ho notato, allora, il file di configurazione /etc/default/grub, contenente la variabile GRUB_CMDLINE_LINUX che imposta i parametri di boot addizionali da accodare alla riga del kernel. Proprio lì  era menzionata la partizione inesistente, per ben due volte, come valore per le opzioni di resume= e real_resume= (necessarie, come è possibile anche notare dal commento di Fabio Erculiani, per il corretto ripristino di una sessione dopo la sospensione su disco). Qualche pigiatina di tasti e anche questo potenziale problema è andato via!