Corsair Force F120 & Overprovisioning - [FOCUS]

[The_Bis]

Il focus che presentiamo oggi ha la doppia funzione di presentare la rinnovata linea di SSD Corsair Force e, allo stesso tempo, di approfondire l'argomento Overprovisioning.

Corsair, come molti altri brand, sta promuovendo una gamma di SSD basati su controller SandForce identici per quanto riguarda gli aspetti hardware rispetto a quelli visti precedentemente, ma differenziati da quanto recensito a questo indirizzo sotto l'aspetto software, più precisamente a livello firmware.

I nuovi Force infatti, nonostante siano dotati dei canonici 64, 128 e 256 GB di NAND flash MLC, contrariamente alle specifiche SandForce allocano una parte molto ridotta di memoria disponibile all'Overprovisioning.

Il risultato di questa scelta contribuisce in maniera sensibile alla diminuzione del costo al gigabyte perchè, di fatto, a parità di hardware e di costo, abbiamo il 20% di spazio disponibile in più.

Di seguito le specifiche dichiarate dei nuovi Force che potremmo definire, usando un termine già adottato anche da OCZ, “Extended”.

Corsair Force CSSD-F60GB2-BRKT CSSD-F120GB2-BRKT CSSD-F240GB2-BRKT

Specifiche tecniche: Fattore di forma - 2,5" Interfaccia - SATA 1,5 Gb/sec. e 3 Gb/sec. Tecnologia - MLC NAND Flash Capacità - 60/120/240 GB Prestazioni - 285MB/s read 275 MB/s write Dimensioni - 69,63 mm x 99,88 mm x 9,3mm Peso - 80 grammi Specifiche alimentazione - Attiva: 2,00W MAX Specifiche alimentazione - Non attiva: 0,5W MAX Durata prevista - 1 milione di ore Tolleranza agli urti - 1.500 G Specifiche alimentazione - 5,0V +/- 5% Garanzia – 3 Anni

[pippo369]

Ottimo focus Stefano, sarà utile a chi ha ancora le idee confuse fra le miriadi di modelli adesso disponibili.

[giostark]

Già indicizzato su googleZZ !!
Ottimo Ste ... letto con molto interesse, ed è stato anche molto scorrevole

[zilla]

Ottimo Stefano come sempre

Concludo dicendo che la qualità delle celle di memoria in un SSD è tutto, per questo vi dico di scegliere solo i modelli che hanno celle di memoria certificate, come gli SSD di Corsair.

Un saluto

[frakka]

Stò leggendo il focus e man mano mi segno le domande:

1_ "Un aspetto fondamentale, gestito a livello di controller, che potremmo definire Overprovisioning dinamico"
Quindi questa funzione di garbage collector+wear levelling operante a livello firmware dovrebbe permettere il mantenimento di un buon livello di prestazioni anche in assenza di supporto TRIM da parte del so. Giusto?
Hai avuto modo di testare un disco SandForce in assenza di supporto TRIM?

2_ "Il comando TRIM opera in modo trasparente rispetto al sistema e solo sulle partizioni attive"
Quindi solo sulla partizione di boot? Avendo due dischi SSD di cui uno dedicato allo storage (anche se è assurdo, ma poniamo il caso) oppure una configurazione multiboot in cui la partizione attiva sia su un disco meccanico e l'installazione di Win7 su SSD il trim non si attiva? Comunque poco male, se quanto supposto al punto 1 fosse vero.

[frakka]

Tempo fà sottoposi a te e BetaXP una domanda relativa al comportamento degli SSD quando usati per archiviare il file disco di una macchina virtuale.
Poco tempo dopo, ad un convegno di GEMM informatica, sottoposi la stessa domanda anche ad una responsabile Microsoft per l'Italia di Windows 2008 SBS che promise di girare la domanda al reparto tecnico e da cui non ho più avuto risposta...

Siccome stò ancora cercando una risposta, più per curiosità mia che altro, faccio alcune considerazioni:
- Se il comando trim lavora solo sulla partizione attiva il fatto di avere il disco riempito magari per il 100% da un vhd non è più così importante, a meno che non si archivino i vhd in C:\ In ogni caso non si trarrebbe beneficio da questa funzionalità nell'uso di una vm.
- Se questa funzione di Overprovisioning dinamico (garbage collection+wear levelling) funziona a livello firmware e non richiede quindi il supporto del s.o. potrebbe supplire in parte all'impossibilità da parte della vm di comunicare al disco su quali aree del disco applicare il trim. Lavorando all'interno di un disco virtuale, io vado a scrivere e modificare sempre una parte delle celle già occupate dal disco virtuale. Su un disco meccanico o una SSD classica, significa che vado a lavorare sempre sugli stessi blocchi di memorizzazione.
Se la componente di wear-levelling del disco provvede a scrivere le modifiche su aree destinate all'overprovisioning allora dovremmo ottenere di scrivere sempre su aree pulite o che sono state ripulite in passato dalla funzione di garbage collector, ottenendo sempre le massime prestazioni.


Ha senso??

[betaxp86]

Per quanto riguarda la questione VM, se il disco è pieno dai VHD soffrirà dei problemi che si hanno con gli SSD pieni per una questione di continua ricollocazione delle celle. Usando dischi ad espansione dinamici (che su HyperV R2 hanno performance simili a quelli statici, il problema dovrebbe essere più ridotto).
Sicuramente usando un disco con Garbage Collector nel Firmware e indipendente dal TRIM, il problema è "risolto", infatti tutti gli OCZ con indelix e FW superiore al 1.5 hanno il GC che lavora in parallelo al TRIM.
Per quanto riguarda il "dove lavora il trim", lavora tutte le partizioni attive, ovvero tutte quelle visibili da Windows, non opera sullo spazio non partizionato.

[frakka]

Per quanto riguarda la questione VM, se il disco è pieno dai VHD soffrirà dei problemi che si hanno con gli SSD pieni per una questione di continua ricollocazione delle celle. Usando dischi ad espansione dinamici (che su HyperV R2 hanno performance simili a quelli statici, il problema dovrebbe essere più ridotto).
Sicuramente usando un disco con Garbage Collector nel Firmware e indipendente dal TRIM, il problema è "risolto", infatti tutti gli OCZ con indelix e FW superiore al 1.5 hanno il GC che lavora in parallelo al TRIM.

Quindi questa soluzione a livello firmware dovrebbe presentare degli indubbi vantaggi anche quando al s.o. si frappone uno strato di gestione, come nel caso di un controller AHCI o RAID. Non dovrebbe quindi essere più necessario mantenere i controller in modalità IDE oppure ho capito male??
I dischi dinamici, prestazioni a parte, introducono altre problematiche da valutare.

Per quanto riguarda il "dove lavora il trim", lavora tutte le partizioni attive, ovvero tutte quelle visibili da Windows, non opera sullo spazio non partizionato.

Ok mi sembra logico essendo una funzionalità comandata da so. Così come non dovrebbe operare sui dischi che il sistema vede come offline, come i pass-through. Ma "partizione attiva" è un'altra cosa se non sbaglio, dovrebbe essere la partizione flaggata come bootabile. Giusto? Grazie delle delucidazioni.

[The_Bis]

Mi scuso per la risposta in ritardo...

Fondamentalmente tutto quello che e' stato scritto non fa una piega, pero' non dimentichiamo che il Trim (in windows 7) lavora con una logica tutta sua talmente "sua" che a mio avviso praticamente ancora potremmo dire che non funziona...

Perche' il trim funzioni in maniera corretta soprattutto con Sandforce è IMPORTANTE lavorare con AHCI, l'IDE è indispensabile solo ed esclusivamente con TRIM manuale.

Per quanto riguarda la questione VHD l'argomento e' interessante e allo stesso tempo devastante... Un file sia esso reale o virtuale che esiste all'interno di una partizione Windows non potrà mai essere trimmabile (per ovvie ragioni) fino a che non venga marchiato come cancellato (riscrivibile in linguaggio ATA) fondamentalmente un VHD è un grande ed unico file che non puo' essere trimmato...

La questione Overprovisioning dinamico e' una furbata che in un controller evoluto come SandForce fa un ottimo lavoro, pero' ti ricordo che si parla di circa 20Gb di celle in "ricambio" e, non dimentichiamo, sempre soggette alle logiche di wear levelling... In un contesto VHD puo' aiutare ma sempre e relativamente alla quantità di spazio occupato...

Pero' non fasciamoci troppo la testa ho provato SandForce, Indilinx e anche Samsung in tutte le condizioni e con o senza trim vanno cmq molto bene. In un VHD non ci dovrebbe essere mai un esagerato traffico in scrittura, ergo non dovresti mai avere problemi di Trim.

Teniamo presente che il Trim si rende necessario solo ed esclusivamente per quello che e' il semplice traffico in scrittura. Solitamente quando un utente il computer lo USA, a parte in fase di installazione, il resto del tempo l'SSD lo passa a scrivere piccoli log/file o archivi di dimensioni irrisorie, eventualmente Prefetch o Paging ma raramente ci saranno movimenti di giga e giga di dati... Quello che rende l'ssd una bomba è la velocità con cui legge e con cui accede ai dati, fattori questi non migliorabili con il TRIM.

Bau!

[frakka]

Per quanto riguarda la questione VM, se il disco è pieno dai VHD soffrirà dei problemi che si hanno con gli SSD pieni per una questione di continua ricollocazione delle celle.

Scusa se insisto, mi rendo conto che posso risultare pesante ma non sono convinto. Ero partito circa due ore fa per scrivere un'altra cosa (non avevo ancora visto il post di Stefano) poi il ragionamento è degradato. Scusate il delirio ma sarà forse anche colpa dell'orario!!

Ipotesi:
La specifica di SandForce su un disco da 128Gb prevede uno spazio riservato di circa 28Gb, di cui 8Gb calcolate per compensare l'usura delle celle e garantire un determinato MTBF e i rimanenti 20Gb dimensionati ad uso e consumo degli algoritmi di garbage collection del firmware.
Nota:
Vedendo i bench che ha postato Stefano, in particolare i write 50% full e 100% full anche lui ha evidenziato una cosa piuttosto anomala e cioè un andamento nel modello Corsair F120 simile a quello che si vedeva sui controller di vecchia generazione o su un raid di dischi meccanici in presenza di gravi problemi di prestazioni e cioè un andamento del grafico stile "sismografo".


Abbiamo ora i due SSD recensiti. Supponendo che siano basati su un identico PCB, la capacità dichiarata riserva per entrambi uno spazio maggiore o uguale a 8Gb per compensare l'usura delle celle il che, assumendo vera l'ipotesi che il MTBF calcolato da SF sia funzione degli 8Gb riservati, consentirebbe di dichiarare lo stesso valore MTBF per entrambe le unità.
Al modello da F120 mancherebbe però quello spazio che nell'ipotesi ho assunto come dimensionato ad uso e consumo degli algoritmi di GC e che giustificherebbe un comportamento prestazionale diverso dei due drive in particolare in condizioni di disco Full.

Andiamo ora ad analizzare i bench postati da Stefano relativamente al write/sequential:
Una generica SSD non SF sottoposta a questo test, presenta un andamento a prestazioni degradate per una lunghezza sul grafico più o meno corrispondente alla percentuale di spazio occupato.

Per ora escludo gli 8Gb che ipotizzo dimensionati per il wear-levelling dal calcolo della capacità massima dei dischi.
Questi dischi SF montano entrambi 128Gb di NAND, di cui 100Gb usabili nel modello F100 (quindi con 20 Gb oltre la capacità dichiarata a disposizione delle funzioni di garbage collection) e 120G usabili nel modello F120 (e quindi senza alcuna capacità aggiuntiva disponibile).

Nel momento in cui il bench sul F100 va a svolgere le sue operazioni di scrittura, vediamo che l'andamento a massime prestazioni riprende poco prima dei 30Gb invece che arrivare fino ai 50Gb che ci si poteva aspettare, recuperando in lunghezza del tratto a prestazioni degradate un valore azzarderei dire molto simile allo spazio riservato per l'overprovisioning.
Nel medesimo test, il disco SF120 recupera le sue massime prestazioni senza alcun margine significativo sul valore dei 60Gb, contrariamente a quello che ci si poteva aspettare vedendo il grafico del fratello minore ma in accordo con il fatto che non vi è in questo disco una capacità aggiuntiva disponibile che può essere utilizzata per recuperare prestazioni.

Nel test "100% full" sul disco F100 vediamo che l'andamento a massime prestazioni riprende... Attorno agli 80Gb! Anche qui recuperando in lunghezza del tratto a prestazioni degradate un valore molto simile allo spazio riservato per l'overprovisioning, non proporzionale allo spazio occupato ma sempre uguale al valore fisso di 20Gb di cui sopra.
Nel medesimo test il disco F120 non recupera mai un andamento prestazionale lineare coerente con i valori medi del modello F100, presentando l'andamento a sismografo per tutta la durata del test.
Tale andamento si presenta solo dove le celle del disco sono allocate, infatti nel bench 50% raggiunta la metà del disco il grafico riprende l'andamento più lineare che si riscontra a disco vuoto. I due dischi presentano tratti comportamentali comuni, caratteristici sicuramente del funzionamento del controller SandForce: a parte l'ampiezza delle oscillazioni, su cui farò un'ipotesi successivamente, in entrambi i grafici si riscontra una riduzione di prestazioni dovuta allo stato di full del disco. Sul modello F120 è molto marcata, molto meno lo è nel modello F100.


Cosa voglio dire:
La maggiore capacità di storage disponibile sui modelli "Extended" penalizza notevolmente in prestazioni il disco basato su controller SF ma, grazie al particolare algoritmo di gestione delle celle del controller, questo problema si evidenzia solo con il disco pieno ed è tanto maggiore quanto maggiore è la percentuale di spazio occupato.
I particolari algoritmi di funzionamento del controller SandForce prevedono l'uso continuo di tutte le celle di memoria a disposizione del controller per ottimizzare le prestazioni in scrittura del disco e garantire il MTBF previsto dalle specifiche. In condizioni di disco vuoto o poco allocato, il controller è in grado di gestire le operazioni di scrittura usando indifferentemente tutte o quasi le celle presenti sulla SSD. Nel caso che l'operazione di scrittura coinvolga però delle celle già occupate in tutto o in parte, l'operazione di scrittura del blocco modificato avviene su celle non assegnate alla "capacità disponibile" del disco e che quindi saranno sempre vuote. Le funzionalità di GC, provvedono poi a liberare la cella precedentemente allocata (e il cui contenuto modificato è stato ora scritto in celle facenti parte della capacità "non disponibile") e che ora è diventata a sua volta parte dello spazio di overprovisioning.

Ovviamente non avendo spazio di overprovisioning, quando deve scrivere su celle già allocate la SSD F120 si comporta come una normale SSD che deve svuotare la cella di destinazione prima di poterci scrivere. Questo spiega sia il degrado di prestazioni a disco completamente pieno (comportamento simile a quello delle vecchie SSD) che l'andamento a sismografo, in quanto questa modalità di lavoro costituisce una forzatura per il controller SandForce, che si trova soggetto a un carico di lavoro notevolmente più elevato di quanto non avvenga invece sulla SSD F100.


E' plausibile quanto sopra??