SDB:Supporto a Idle Time Garbage Collection per SSD


Provato su openSUSE Articoli consigliati Articoli correlati
Icon-checked.png

Icon-manual.png Icon-help.png
Questo articolo verte su una specifica caratteristica dei dispositivi SSD e se tale funzionalità sia supportata in openSUSE oppure no. La risposta non è un semplice sì o no. E neppure è semplicemente questione di elencare le unità SSD supportate a fronte di quelle che non lo sono. E' invece importante che il lettore capisca cos'è la funzionalità nota come "Idle Time Garbage Collection" (Garbage Collector durante il tempo di inattività).

Terminologia

Erase Block - EB - I dispositivi SSD sono costruiti attorno alla tecnologia dei gate di tipo Nand. L'elemento costruttivo di partenza è il chip di memoria Nand che funziona a blocchi di dati. Internamente il chip Nand è organizzato a blocchi di cancellazione (erase block). La tecnologia di cancellazione non consente la cancellazione di una porzione di blocco (erase block). Il funzionamento è di tipo o tutto o niente, perciò il termine Erase Block (Blocco di cancellazione), o EB, ha finito per indicare il più piccolo blocco che il chip Nand riesce a cancellare. Tipicamente i blocchi EB sono molto più grandi dei settori usuali o anche delle pagine di un filesystem pages. La dimensione più comune dei blocchi EB è, infatti, attualmente di 128KB.

Discard, UNMAP e TRIM: sono questi i tre termini spesso usati per indicare in maniera intercambiabile la medesima funzionalità di base.

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.

Perché le unità SSD hanno bisogno di un garbage collector?

In generale tutte le moderne unità SSD hanno bisogno di un consolidatore di Erase Block (EB). Le unità SSD recenti hanno dei blocchi di cancellazione (EB) che tipicamente hanno dimensione pari a 128KB, ma consentono a tali blocchi EB di contenere pagine di dati non adiacenti.

Alcuni produttori di dispositivi SSD fanno riferimento a tale funzionalità col nome di Garbage Collection. In particolare SandForce la definisce Idle Time Garbage Collection.

Per quanto riguarda il consolidamento dei blocchi EB nelle SSD, il concetto chiave da comprendere è che il riutilizzo degli EB è di tipo o tutto o niente, non parziale. Per riscrivere una qualsiasi parte dei dati è necessario prima cancellare l'intero blocco di cancellazione (EB), poi riscriverlo in toto. Nei dispositivi tascabili molto lenti ed economici, in accordo con questa restrizione le velocità di scrittura possono scendere all'ordine delle decine di MB/minuto.

In unità SSD decenti sono invece stati implementati degli algoritmi molto più complessi per rendere il dispositivo molto più reattivo. Queste unità di solito non solo sono veloci quanto i dischi di tipo rotativo, bensì sono spesso di gran lunga più veloci nel caso di applicazioni con flusso dati input/output (I/O), casuale.

Si può quindi assumere che l'unità SSD tracci e mappi i dati in pagine, o blocchi, di 4KB, anche se è strutturata a blocchi EB di 128KB. In tal modo un EB appena allocato e scritto conterrebbe tipicamente 32 pagine di 4KB ciascuna.

Se alcune delle pagine vengono sovrascritte dal normale utilizzo del filesystem, l'azione più efficiente da farsi per l'unità SSD è di segnare come libere (non più in uso) le pagine sovrascritte nel blocco EB allocato, e mettere le nuove in pagine in coda per essere inviate al nuovo blocco EB che sarà allocato. Quando l'unità SSD arriverà 32 pagine di nuovi dati messi nella coda, allocherà un nuovo EB e vi scriverà sopra i dati. Naturalmente quando avviene tale operazione il dispositivo provvede anche ad aggiornare le tabelle delle corrispondenze, o mappature, tra dati logici e fisici.

Sembra una soluzione molto intelligente, se non si considera il blocco EB di partenza. Man mano che i dati vengono segnati come non più validi, a causa della sovrascrittura, si va da 32 pagine su 32 in uso, cioè il massimo numero disponibile, a sempre meno pagine di blocchi di dati validi in uso. Ad un certo punto il controller dell'unità SSD si accorge dello spreco di spazio e si appresta a consolidare quei blocchi EB parzialmente in uso.

E' possibile osservare che il consolidamento degli EB è richiesto anche in mancanza del supporto a livello del sistema operativo. E non è necessario che disponga dell'informazione su com'è organizzato il filesystem, o altro.

Nel caso in cui l'unità sia piena al 100%, o prossima a tale valore, nascono dei problemi: i blocchi EB tenderanno anch'essi ad essere piuttosto pieni, per cui ci si può facilmente ritrovare con tutti gli EB in uso e il 75% o più di dati utili. Con una percentuale media di blocchi in uso così elevata risulta assai difficile che il consolidatore si comporti in modo efficiente.

Per queste ragioni nel periodo tra il 2007 e 2008 è stato introdotto il concetto dell'operazione di trim. Lo scopo del comando è di permettere all'unità SSD di avere maggiori informazioni su quali pagine sono realmente in uso, verso quelle che non lo sono e, con questa informazione, di essere in grado di consolidare in modo più efficiente i blocchi EB per la successiva cancellare in background.

Perciò i consolidatori di Erase Block come Idle Time Garbage Collection, di SandForce, sono implementati direttamente nel dispositivo SSD e non necessitano del supporto da parte di Linux per funzionare. Tuttavia assicurarsi che sul proprio dispositivo SSD venga eseguito trim permetterà all'unità di essere meglio aggiornata su quali pagine di memoria sono diventate libere e quindi permetterà all'intero processo di funzionare meglio.

Vedere anche

Articoli correlati

Collegamenti esterni