Debian e SSD

Attenzione: questo articolo è ancora incompleto e in fase di scrittura da parte del suo autore. Sentitevi liberi di contribuire, proponendo modifiche alla guida tramite l'apposita pagina di discussione, in modo da non interferire con il lavoro portato avanti sulla voce. Per altre informazioni si rimanda al template.

Versioni Compatibili Tutte le versioni supportate di Debian

Prefazione

Lo scopo di queste guida è quello di aiutare a configurare un sistema debian (da installare o esistente) per un utilizzo adeguato con una SSD. La guida tratterà innanzitutto i passaggi obbligatori (nel senso quelli che sono fondamentali per una corretta durata della nostra SSD) ed infine quelli facoltativi (in quanto ci possono essere delle linee di pensiero molto differenti in una configurazione mista HDD/SSD su cosa debba essere di competenza della SSD e cosa dell'HDD).

Partizionamento e Over Provisioning

Prima di tutto per poter utilizzare la nostra SSD è necessario partizionarla. Il consiglio, anche se state utilizzando un sistema non EFI, è quello di utilizzare un sistema di partizionamento GPT e non MBR in quanto immensamente superiore. Quindi se state installando debian e siete nell'utility di installazione andate su una console virtuale (ctrl+alt+f2) e procedete come segue. Se invece non siete nell'utility di installazione di debian la procedura è identica.

Prima cosa individuiamo quale è il device dell'unità con il comando

# fdisk -l

per il partizionamento però dobbiamo usare cfdisk in quanto l'altro non supporta GPT. Quindi lanciamo

# cfdisk /dev/sdX

dove /dev/sdX è il nome del nostro device. A questo punto bisogna pensare a come partizionare il nostro dispositivo. Ci sono molte teorie sul partizionamento. (Tutto in una partizione. Partizioni separate. Solo la /home su HDD, /home e /var su HDD. /home /var e /tmp su HDD. /home e /var su HDD e /tmp su RAMDISK e soprattuto dove mettere la SWAP. La scelta è molto personale ed è anche dettata dalla dimensione della vostra SSD, dalla quantità di RAM che avete e dai gusti.

Personalmente sono amante della mono-partizione con SWAP su SSD (permette una ibernazione e un risveglio quasi istantaneo) e una maggiore versatilità del sistema. /var, /home e /tmp le metto nella SSD in quanto per quanto riguarda /var voglio una lettura veloce dei file in essa presenti. Per quanto riguarda /tmp come /var e non voglio sprecare la RAM per creare un RAMDISK. Se però gradite fare ciò o volete creare un RAMDISK persistente troverete la guida sotto.

Anche la /home la metto su SSD in quanto voglio che la lettura dei files di configurazione, della cache del brower ed altro siano letti il quanto più velocemente possibile. Voi mi direte, ma la SSD ha una durata in letture e scritture rispetto all'HDD. Vero, ma per quante scritture ci faccio sarà obsolete prima che la rompa. Per quanto riguarda invece i files più grandi ovvio montando l'HDD in /mnt e mettendo dei link simbolici nella home che puntano in una directory nell'HDD con i permessi del mio utente.

Mentre si partiziona il disco bisogna tenere a mente una cosa importante: l'over provisioning. Esso consiste nel lasciare dello spazio non partizionato. Questo spazio libero viene usato dal controller della SSD sia come spazio di SWAP durante il trim, sia come riserva nel caso dei settori siano danneggiati che per il garbage collection che lavora quando il disco non è in uso. Insomma questo spazio non partizionato serve per allungare la vita del vostro SSD. Molti produttori, come SAMSUNG riservano dello spazio in trasparenza (all'oscuro) del'utente per l'over provisioning, ma non è sufficiente. Kingston consiglia di lasciare almeno un 7% di spazio non allocato in utilizzo client e un 28% per un utilizzo enterprise. Poi sta all'utente scegliere quanto spazio lasciare in base all'utilizzo che intende fare del disco.

File System

Il miglior file system da usare per la SSD è EXT4. Anche Btrfs supporta gli SSD con uno speciale comando di mount, ma io lo sconsiglio perché EXT4 è più stabile, meno soggetto a corruzione, insomma è meglio.

Se volete risparmiare scritture non usate EXT2, se mai montate EXT4 senza il journal, ma comunque il journal tenetevelo. Perché rischiare di corrompere il file system a causa di un calo di tensione oppure un crash (ok che linux è stabile, ma qualche crash può sempre succedere)? Il journal è buono!