SDB:Supporto a SSD discard (trim)
| Provato su openSUSE | Articoli consigliati | Articoli correlati | |||
|
|
|
|
||
Indice
Terminologia
Ci sono tre termini spesso usati per indicare in maniera intercambiabile questa medesima funzionalità di base: Discard, UNMAP, e TRIM.
Discard (it.: scarta) è il termine usato nel kernel linux per comunicare al dispositivo di archiviazione che i settori non contengono più dati validi e si applica ugualmente sia a dispositivi ATA che SCSI. In effetti per il filesystem ext4, esiste l'opzione discard per il comando mount, non un'opzione trim o unmap. Storicamente questa funzionalità non esisteva, ma di recente i produttori di SSD hanno richiesto questo capacità per aumentare le prestazioni dei loro prodotti e i produttori di array SCSI hanno richiesto una funzionalità simile per avere un supporto migliore al Thin provisioning.
Sarebbe perciò naturale scartare piccoli intervalli di settori con un'unità SSD, ma solo intervalli ampi con un array SCSI. In effetti alcuni array SCSI possono rimuovere intervalli fino ad un limite di 4 MB. L'implementazione dell'array è specifica a seconda della modalità in cui sono rimossi gli intervalli.
TRIM è l'effettivo comando ATA-8 che viene inviato all'unità SSD per far sì che un intervallo di settori o un insieme di intervalli di settori vengano scartati (segnati come non più in uso). Come tale si dovrebbe solo applicare ai dispositivi ATA, ma viene spesso usato in modo generico. Data la prevalenza di dispositivi ATA, trim è spesso il termine più usato tra i tre.
UNMAP è un comando specifico per l'interfaccia SCSI, simile per funzionalità ai precedenti, ma concepito principalmente per supportare il Thin provisioning. Anche UNMAP è spesso usato come termine un generico invece che riservato ai dispositivi SCSI.
L'interfaccia SCSI supporta anche WRITE SAME che può essere anche usato per implementare la funzione di scarto dei settori (discard). Per ora WRITE SAME risulta usato soltanto per il suo specifico campo di impiego.
La situazione
Utilizzare la nuova generazione di unità SSD vuol dire applicare soluzioni soggette a cambiamenti. Le operazioni di base dovrebbero essere supportate con tutti i rilasci di openSUSE, ma la funzionalità discard, ovvero trim, è ancora in corso di implementazione, perlomeno per quanto riguarda un'implementazione completa. Le unità SSD saranno presto comuni nei laptop. Per ottimizzare le loro prestazioni e prolungarne la durata le specifiche ATA-8, in corso di definizione (stato di bozza), richiedono il supporto a trim. Se a un intervallo di settori è applicato trim, allora quei settori non contengono più dati significativi e il dispsitivo SSD è libero di eliminarne i contenuti e cancellarli. La cancellazione è un'operazione lenta per un'unità SSD, perciò poter cancellare i settori quando sono liberi, invece che quando sono in uso, è un grande vantaggio.
Sfortunatamente si può ottenere questo solo se l'implementazione per spazio utente (userland), kernel a hardware è ottimizzata allo scopo. Dagli inizi del 2010 l'unica implementazione ottimizzata è una puramente in spazio utente (userland) che funziona in modo simile alla deframmentazione, ovvero è pensata per essere invocata a periodi fissati, per esempio da uno script per cron.
Stato attuale
Per versioni di openSUSE precedenti la 11.2 non esiste supporto per trim.
A partire dalla versione 11.4 fstrim fa parte del pacchetto linux-util e per la maggior parte degli utenti è il modo raccomandato di richiamare il comando trim.
Supporto da parte del Kernel
Supporto del Kernel a discard in tempo reale (realtime discard)
I kernel in openSUSE 11.2 e successivi supportano realtime discard. Ovvero mentre i file vengono eliminati i corrispondenti blocchi dei dati vengono scartati. Questi kernel supportano realtime discard per ext4 e xfs.
Per usare la funzione di discard in tempo reale del kernel si devono montare le partizioni con l'opzione "mount -o discard". openSUSE non imposterà automaticamente questa opzione, per cui è necessario o montare manualmente la partizione, o aggiornare il proprio file /etc/fstab perché esegua il montaggio con quella opzione.
L'implementazione del kernel di realtime trim (trim in tempo reale) in 11.2, 11.3, e 11.4 non è ottimizzata. Le specifiche richiedono per supportare trim una lista vettorizzata di intervalli di settori a cui applicare trim, ma, fino al kernel 3.0, trim è soltanto invocato dal kernel con un singolo intervallo di blocchi da scaricare (ovvero a cui applicare discard / trim) e con le attuali unità SSD di metà del 2011 è stato appurato che ciò causa un degrado delle prestazioni invece che un aumento delle stesse. Esistono poche ragioni per sfruttare il supporto del kernel a realtime discard con le versioni del kernel precedenti la 3.1. Non è noto quando la funzionalità di discard del kernel verrà ottimizzata in modo tale da funzionare efficacemente con la generazione corrente di unità SSD.
Supporto del Kernel a discard per i dispositivi di swap (discard swap device)
Il kernel linux dalla versione 2.6.29 supporta discard per le pagine della memoria di swap che non sono più utilizzate. L'impatto sulle prestazioni è variabile e può avere effetti positivi oppure negativi per una particolare unità SSD.
In openSUSE 11.2 e 11.3 non è presente un modo per controllare questa caratteristica. Il kernel si comporterà come se fosse vantaggiosa per tutti i dispositivi che supportano discard.
Nel kernel 2.6.36 è stata introdotta un'opzione controllata da spazio utente (in userspace). In openSUSE 11.4 il supporto al controllo in userspace è disabilitato per impostazione predefinita. Una versione di util-linux-ng maggiore della v2.18 è richiesta per abilitare la funzionalità discard. (Si noti che util-linux-ng è stato rinominato util-linux all'inizio del 2011.)
Per i dettaglio si veda http://marc.info/?l=util-linux-ng&m=128796678428160
Supporto del Kernel a discard con mkfs
Una recente ottimizzazione del kernel che avrà effetti sulle nuove partizioni in ext4 create con openSUSE versione 11.4 e più recenti è che il programma di formattazione in ext4 mke4fs applicherà discard all'intera partizione al momento di formattare; inoltre il processo è stato ottimizzato nel kernel in modo da usare 64 intervalli contigui per il comando TRIM. Come tale è ben ottimizzato. Per questioni di prestazioni è importante che le partizioni appena create abbiano tutti i loro blocchi non in uso scaricati (ovvero in stato di TRIM applicato) al termine del processo di formattazione. Perciò si raccomanda vivamente di usare mkfs fornito da openSUSE 11.4, o versioni successive, quando si formatta su un'unità SSD che conteneva in precedenza dati validi.
Supporto del Kernel a batched discard (discard a gruppi di blocchi)
Il kernel 2.6.37 ha ottenuto un nuovo ioctl solo per ext4: FITRIM. openSUSE 11.4 usa tale versione del kernel: il tool di openSUSE 11.4 per richiamare nello spazio utente (userspace) questa nuova funzionalità è fstrim. Per le versioni meno recenti fstrim è attualmente disponibile tramite git all'indirizzo:
http://www.spinics.net/lists/util-linux-ng/msg03646.html
Una caratteristica di fstrim / FITRIM che non è completamente supportata attraverso l'uso di wiper.sh (vedi più sotto) è il supporto a discard per il device mapper di tipo lineare (linear device mapper) e i volumi di tipo stripe:
Ancora più significativo è il fatto che FITRIM è stato accettato tra le funzionalità principali del kernel e come tale riceve una revisione più diffusa e approfondita di wiper.sh qui sotto. Per questo FITRIM (richiamato da fstrim) dovrebbero porbabilmente causare molte meno perdite di dati se si tenta di usarlo in un ambiente non supportato.
Supporto in Spazio utente (Userland)
Lo strumento raccomandato per eseguire il trim sulle unità SSD in openSUSE 11.4 è fstrim dal pacchetto util-linux (o util-linu-ng). Il programma deve essere invocato una volta ogni tanto, proprio come si farebbe con uno strumento di deframmentazione (defrag). Impostarlo in modo che sia richiamato da cron dovrebbe essere il miglior modo praticabile.
Le versioni precedenti a openSUSE 11.4, ovvero sia la 11.2 che la 11.3, contengono versioni aggiornate di hdparm che riescono a bypassare i normali livelli di I/O (input/ output) a blocchi (block I/O layers) e ad inviare direttamente i comandi di trim ottimizzati alla unità SSD. hdparm richiede uno script di controllo per determinare quali settori sono idonei per essere segnati come inattivi, mediante l'applicazione del comando trim. Questo controllo è realizzato nel pacchetto hdparm dallo script wiper.sh che è disponibile nei pacchetti di hdparm sia per openSUSE 11.2 che 11.3.
Fino ad ora né openSUSE 11.2 né 11.3 richiameranno wiper.sh in modo automatico. Sarà cura dell'utente creare uno script per cron adatto a questo scopo. In generale il tempo di esecuzione di wiper.sh dovrebbe essere soltanto di alcuni secondi, il comando deve essere eseguito come utente root.
Quanto spesso si dovrebbero eseguire fstrim o wiper.sh?
Per la maggior parte degli utenti una volta alla settimana dovrebbe essere sufficiente. Il tempo tra due esecuzioni successive potrebbe sembrare troppo lungo, tuttavia dovrebbe funzionare bene finché non si stia eseguendo un carico di lavoro che implichi la creazione e l'eliminazione di quantità molto grandi di file (non vuoti), a ritmi elevati.
In base alla teoria un'unità SSD gestisce le aree riconosciute come libere (non più usate) con una pila in logica LIFO e sono necessari solo pochi millisecondi, dopo che un blocco è stato inserito nella pila LIFO, prima che venga cancellato e sia pronto per essere rimosso dalla cima della stessa. Quindi, finché si ha a disposizione un numero sufficiente di blocchi cancellati, l'unità può funzionare alla massima velocità, spingendo i blocchi appena liberati nel fondo e prelevando i nuovi blocchi cancellati dalla sommità della pila.
Se il carico di lavoro fosse un database, concettualmente ogni scrittura andrebbe in un blocco appena allocato, mentre il vecchio blocco diventerebbe immediatamente inutilizzato (e liberato) e posto nella coda di cancellazione. Con le nuove generazioni di unità SSD sembra che un garbage collector sia eseguito dietro le quinte dal firmware interno degli SSD per raccogliere e ripulire queste aree sovrascritte dell'unità SSD e rendere quello spazio disponibile per il futuro utilizzo in modo efficiente.
In altre parole le unità SSD non consentono che i blocchi fisici dei dati vengono aggiornati. Ogni scrittura richiede che un nuovo blocco di dati venga prelevato dallo stack (o pila) dei blocchi liberi (non più in uso), e che il precedente blocco fisico sia liberato per la cancellazione. Perciò un processo come un database che continua ad aggiornare i blocchi di dati precedentemente allocati causa solo una gran attività sul disco, ma non rende affatto più piccolo lo stack dei blocchi liberi.
(Nota: La più recente generazione delle unità SSD non funziona più come descritto sopra. Risulta invece che queste ultime tengano traccia della memoria in uso e non più in uso (libera) ad un livello caratterizzato da una maggiore granularità del livello del blocco di cancellazione (EB, Erase Block level). Perciò un continuo aggiornamento derivante da un'attività di tipo database fa sì che una porzione di un EB sia segnata come libera e un nuovo EB sia allocato per contenere i nuovi dati. Di conseguenza gli aggiornamenti per una pesante attività tipo database possono causare una scarsità di EB liberi, a causa di tutti gli EB parzialmente utilizzati che vengono via via messi da parte. I Moderni SSD per far fronte a questo problema usano un consolidatore di blocchi di cancellazione (EB consolidator), in esecuzione in background. Avere le unità SSD opportunamente sottoposte a trim consente al consolidatore di EB di funzionare con prestazioni ottimali. Vedere en:SDB:SSD_Idle_Time_Garbage_Collection_support per maggiori dettagli.)
Con l'eliminazione di un file si fa sì che l'unità SSD consideri ancora quei blocchi come utili e quindi non disponibili per la cancellazione, mentre il filesystem sa che quei blocchi non saranno più usati.
Quindi il solo scopo di eseguire wiper.sh o fstrim è di comunicare all'unita SSD di mettere i blocchi non più allocati nella coda dei blocchi da cancellare / liberi.
Finché quell'unità SSD non stalla cercando di prelevare i blocchi dalla parte finale di quella coda, non ha davvero alcuna importanza quanto questa sia ampia. Quindi se si dispone di 10GB di spazio libero sulla partizione, è sufficiente richiamare wiper.sh o fstrim ogni volta che si sia cancellata una quantità di file pari a 10GB.
Bug eventuali di hdparm
E' disponibile un aggiornamento in linea per hdparm che corregge il bug citato più sotto.
- Per openSUSE 11.2 e openSUSE 11.3 si può installare l'aggiornamento in linea tramite:
zypper in -t patch hdparm-3298
Resoconto del bug 635920, corretto dalla patch hdparm-3298
Per i dispositivi SSD OCZ Vertex 2E, vedere https://bugzilla.novell.com/show_bug.cgi?id=635920
Inoltre, secondo Mark Lord, il maintainer di hdparm, le unità SSD di Intel non forniscono per trim un supporto completo e in conformità con la bozza delle specifiche, e sono affette dallo stesso bug. Di conseguenza lo script wiper.sh, o lo stesso file binario hdparm sono stati aggiornati nel tentativo di fornire supporto alle unità SSD di Intel.
Gli aggiornamenti sono stati fatti per hdparm v9.32 e poi resi retro-compatibili con openSUSE 11.2 e 11.3 per l'aggiornamento in linea citato più sopra.
Nonostante wiper.sh sia ancora considerato sperimentale, si ritiene con sufficiente certezza che eseguire wiper.sh su una qualsiasi unità SSD non causerà alcuna perdita di dati. Eventuali incompatibilità di trim con i blocchi dati su cui agisce dovrebbero semplicemente causare l'impossibilità per lo stesso di portare a termine le proprie operazioni. Per quanto riguarda l'aggiornamento in linea accennato sopra, non ci sono problemi conosciuti.
Segnalazioni degli utenti
Commento dalla mailing list del kernel dedicata a EXT4
From: Mark Best
Possiedo un nuovo Solid State Drive Vertex2. Quando cerco di installare una qualche distribuzione usando EXT4 (o LUKS con EXT4) il disco rigido va in timeout durante la fase di 'copiatura dei file'. (OpenSUSE 11.2 per esempio va in crash dopo il secondo file di X11. Altre distro proseguono un po' nell'installazione prima di ricevere errori di 'read-only'.)
DISTRO PROVATE:
- Ubuntu 10 - x64
- Debian 5 - x64
- PCLinuxOS 9 - x32
- CentOS 5.4 - x64
- OpenSUSE 11.2 (Linux 2.6.31) - x64
- OpenSUSE 11.3 - Build 0625 (Linux 2.6.34) - x64
Prove:
- Usando il mio disco Seagate da 1TB riesco ad installare senza problemi su qualunque partizione EXT4. (Con stesso cavo SATA e porta del controller SATA)
- Usando il filesystem EXT2 sul mio SSD Vertex2 riesco ad installare qualunque distro.
- Anche Windows 2003/NTFS si installa senza problemi sull'SSD Vertex2.
- Scrivere dati casuali con 'dd' sull'intero SDD non dà alcun errore.
- Aggiornare il BIOS della scheda madre EVGA all'ultima versione (P33) è stato inutile.
- Installare openSUSE 11.2 OS sul mio HDD, e poi copiare i file dall'HDD al Vertex2 provoca lo stesso timeout/remount di I/O (input/ output) negli errori di read only.