[SSD] TRIM vs Background Garbage Collection

[enetec]

Originariamente inviato da K Reloaded

quindi prescindendo dalle ottimizzazioni, se ho ben capito tu equipari le due 'istruzioni' ... però c'è da dire che una viene effettuata via SW l'altra via HW (sempre che abbia capito bene) e se la mia esperienza non m'inganna un'operazione effettuata via HW è tendenzialmente meglio che una effettuata via SW ... tralascio la spiegazione logica di questo in quanto mi pare lapalissiano.

Per la precisione via "firmware" (del controller incluso nelle SSD)...

Per il resto io la penso allo stesso modo.

Anche "concettualmente parlando", ritengo più corretto che un'unità sia in grado di "mantenersi da sola" e non con gli "aiuti da casa" del SO...

[enetec]

Originariamente inviato da zenzip

Non esattamente ...

Gli Hard Disk tradizionali sono soggetti a quel tipo di calo prestazionale per un fatto molto semplice, dovuta alla loro architettura meccanica piatto-testina, cosa che negli SSD non c'è vista l'assenza di parti meccaniche in movimento, così si spiega anche la forza degli SSD nell'accesso casuale contro i piatti rotanti di mazinga a 10k rpm .

Mai sostenuto il contrario... di più, sono vincenti anche contro i SAS da 15k rpm...

Facevo solo notare che, se con gli SSD abbiamo "qualche problema prestazionale" quando sono quasi pieni, con gli HDD... pure!
(da qui tecniche come lo "short stroking" sugli hard disk... utilizzatela sugli SSD e vedrete se la "garbage collection" funziona bene dopo!!! )

Originariamente inviato da zenzip

Quindi il decadimento prestazionale degli SSD in generale dovuto alla saturazione del disco è frutto di quelle operazioni che alcuni post fa ho descritto come "lscrivi-cancella-scrivi-scrivi-cancella-scrivi-scrivi....etc."

Detto ciò per quanto riguarda gli SSD OCZ oggetto della discussione, sicuramente vale quello che hai scritto tu, purtroppo è una scelta costruttiva di OCZ con delle controindicazioni non indifferenti.

E' principalmente un discorso commerciale: alla OCZ non sono stupidi (tutt'altro!).

Se hanno visto che riescono a vendere dei dischi da 60 GB invece che da 50 ad un prezzo competitivo, di poco superiore ai 50 della concorrenza - guadagnandoci peraltro di più... dato che per loro l'unica differenza è nel firmware! - e con prestazioni, tutto sommato, similari, perché non farlo?

Originariamente inviato da zenzip

Sicuramente sono tecnologie con grossi margini di miglioramento, e credo che la volontà dei produttori sia quella di trasferire il grosso dell'overhead sui controller rendendo così queste funzionalità indipendenti dai sistemi operativi e dalle configurazioni degli utenti, insomma la filosofia è sempre quella del plug-and-play

Esatto. Ed è secondo me quella più corretta anche "concettualmente", come dicevo anche nel precedente post...

Originariamente inviato da zenzip

Cmq in generale l'algoritmo di Garbage Collection non sostituisce il TRIM ma sono complementari, ecco anche il perché uno viene implementato via firmware e l'altro a livello software(o quasi).

Se hai analizzato in dettaglio come funziona a livello "di logica" un algoritmo di "background garbage collection" (o, più correttamente, di "idle garbage collection"...) ti sarai reso conto che fa esattamente le stesse cose del TRIM.

Solo in maniera diversa.

Per fare un paragone esemplificativo con i vecchi hard disk, è come avere due differenti programmi di deframmentazione: uno più immediato e rapido ma da eseguire manualmente (tipo XP...), l'altro che lavora in background in maniera autonoma quando ritiene sia il caso (tipo Win 7)...

Alla fine, in un modo o nell'altro, il risultato è il solito: un disco deframmentato.

Se, per il momento, il TRIM appare più efficace è, a mio modestissimo parere, solo perché è più semplice da implementare e pertanto più avanti nella "messa a punto"... esattamente come una volta si credeva che la deframmentazione si potesse fare solo un modalità "monotasking a bocce ferme". Poi siamo passati alla deframmentazione a windows in funzione, infine addirittura a quella autonoma in background...
(e proprio ora che è ottimizzata, con gli SSD non servirà più! )

Ma sono pressoché certo che il futuro (vista anche l'impossibilità tecnica, salvo "miracoli"... di implementare il TRIM in configurazioni RAID, soprattutto quelle avanzate!) sarà per l'adozione della garbage collection in maniera più universale...

Il problema semmai è un'altro... che, temo, almeno in determinate configurazioni RAID anche un'algoritmo di garbage collection potrebbe trovare moolte difficoltà ad operare al meglio...


Per stemperare un po' la tensione che si è creata qui sull'argomento... vi lascio con questo video che sicuramente... vi colpirà!

P.S.: volete diventare ricchi? Ideate un algoritmo concettualmente valido per far funzionare il TRIM anche su configurazioni RAID e proponetelo ad un produttore di SSD a caso...

[The_Saint]

Originariamente inviato da K Reloaded

quindi prescindendo dalle ottimizzazioni, se ho ben capito tu equipari le due 'istruzioni' ... però c'è da dire che una viene effettuata via SW l'altra via HW (sempre che abbia capito bene) e se la mia esperienza non m'inganna un'operazione effettuata via HW è tendenzialmente meglio che una effettuata via SW ... tralascio la spiegazione logica di questo in quanto mi pare lapalissiano.

Il TRIM viene effettuato via hardware... il sistema operativo manda semplicemente il comando di cancellazione dei file ed il firmware dell'SSD fa tutto il resto.

Quindi non parlerei di operazioni effettuate dal software o dall'hardware, ma di operazioni attivate dal sistema operativo ed operazioni indipendenti dal SO.

Cmq fra TRIM e Background Garbage Collection è preferibile il TRIM... il BGC deve essere molto aggressivo per essere efficace, ma questo va a discapito della write amplification ed è per questo che molti produttori non lo implementano nei loro SSD.

Discorso diverso andrebbe fatto (come ho già detto) per i SandForce, dato che il loro algoritmo GC è completamente diverso da quello degli altri...

[gam76]

Mi sono sciroppato tutte le pagine mi sento quasi preparato

[S3N]

• Senza il BGC il Trim sarebbe molto meno efficace.

• Il GC (e di conseguenze il BGC) ed il TRIM non possono funzionare indipendentemente dal SO.

• Dove si crede non sia implementato il BGC (come per gli Intel) in realtà vi sono algoritmi che, proprio per evitare un aumento della WA con consumo di cicli di scrittura, adottano una sorta di BGC molto più blando che agisce su un ridotto numero di celle nand per volta.

[enetec]

Originariamente inviato da The_Saint

Il TRIM viene effettuato via hardware... il sistema operativo manda semplicemente il comando di cancellazione dei file ed il firmware dell'SSD fa tutto il resto.

Quindi non parlerei di operazioni effettuate dal software o dall'hardware, ma di operazioni attivate dal sistema operativo ed operazioni indipendenti dal SO.

Esatto. Per la precisione: entrambi sono eseguiti dal firmware del disco: il TRIM mediante "imbeccata" da parte del sistema operativo, i BGC (quale che sia...) in maniera del tutto autonoma.

Originariamente inviato da The_Saint

Cmq fra TRIM e Background Garbage Collection è preferibile il TRIM... il BGC deve essere molto aggressivo per essere efficace, ma questo va a discapito della write amplification ed è per questo che molti produttori non lo implementano nei loro SSD.

Discorso diverso andrebbe fatto (come ho già detto) per i SandForce, dato che il loro algoritmo GC è completamente diverso da quello degli altri...

Esatto. E' quasi un "TRIM autonomo" (tanto che lo definiscono "Native TRIM"...)

Purtroppo questa parte "intelligente" del loro GC è quella che più facilmente avrà difficoltà a funzionare in configurazioni RAID (per motivi similari alle difficoltà tecniche di passare il TRIM da parte dell'OS in tali configurazioni...), pertanto temo che anche gli stessi finiranno per divenire GC "stupidi" implementati da molti altri produttori...

Il problema, nel caso del RAID, è che manca la collaborazione "nel mezzo", da parte del controller (e relativo driver) cioè!

Solo lui sa "come" ha virtualizzato il sottosistema dischi verso il sistema operativo e come ha suddiviso i dati scritti fra gli stessi verso i dischi.

Perché il tutto funzioni servirebbe un protocollo preciso mediante il quale l'OS possa inviare il TRIM non direttamente al disco bensì al driver del controller, il quale, in base al tipo di RAID implementato ed alla logica di gestione, dovrebbe "tradurlo" in singoli comandi TRIM (diversi ma da quello originario derivati...) da inviare ai singoli dischi.

Fino a che questo non verrà implementato sia l'OS che i dischi avranno difficoltà a svolgere i loro compiti (l'OS per l'impossibilità nell'inviare il TRIM, i dischi per la difficoltà nell'interpretare i dati scritti su di loro così da poter effettuare quella specie di "TRIM autonomo" che gli OCZ più recenti già svolgono e di cui si parlava sopra... )

[enetec]

Originariamente inviato da S3N

• Il GC (e di conseguenze il BGC) ed il TRIM non possono funzionare indipendentemente dal SO.

Non proprio... il sistema di BGC "intelligente" di OCZ (chiamiamolo Native TRIM se vogliamo...) - da quello che ho capito - vi riesce perché "legge" in autonomia il contenuto del disco.

Per cui fino a che si utilizzano FileSystem che è in grado di "leggere" è in grado di lavorare anche in autonomia.

Il problema col RAID è che, vada per il RAID1, ma con lo 0 ed il 5 ad esempio, il singolo disco che legge? Come fa a comprendere "frazioni" di dati?

Ecco che l'aiuto da parte dell'OS, per mezzo della comunicazione via driver che al momento manca del tutto, diviene fondamentale...

[The_Saint]

Originariamente inviato da S3N

• Senza il BGC il Trim sarebbe molto meno efficace.

• Il GC (e di conseguenze il BGC) ed il TRIM non possono funzionare indipendentemente dal SO.

• Dove si crede non sia implementato il BGC (come per gli Intel) in realtà vi sono algoritmi che, proprio per evitare un aumento della WA con consumo di cicli di scrittura, adottano una sorta di BGC molto più blando che agisce su un ridotto numero di celle nand per volta.

Sono un po' sibilline queste affermazioni... puoi spiegarti meglio?

1. Non vedo il nesso...

2. Il TRIM ok... il BGC perchè no?

3. Se così fosse, non si spiegherebbe il calo delle prestazioni... anche se meno aggressivo, il BGC renderebbe cmq l'SSD meno soggetto al degrado, invece dalle prove effettuate sui G2 ed altri modelli, si è riusciti a riprodurre facilmente mediante test lo "stato di degrado"...

[S3N]

Originariamente inviato da enetec

Non proprio... il sistema di BGC "intelligente" di OCZ (chiamiamolo Native TRIM se vogliamo...) - da quello che ho capito - vi riesce perché "legge" in autonomia il contenuto del disco.

Per cui fino a che si utilizzano FileSystem che è in grado di "leggere" è in grado di lavorare anche in autonomia.

Mi citi una fonte nella quale viene affermato che il GC di OCZ (e non il BGC) riesce ad interpretare gli LBA riguardanti i blocchi da considerare modificati all'interno delle pagine delle nand senza ricorrere al sistema operativo e basandosi solo sul tipo di file system?

Originariamente inviato da The_Saint

Sono un po' sibilline queste affermazioni... puoi spiegarti meglio?

1. Non vedo il nesso...

Il nesso sta nel avere ben in mente cosa è il TRIM.
Il SO passa un comado SATA all'SSD indicandogli gli LBA dei dati da cancellare.
A questo punto l'ssd nelle routine di GC prende le pagine delle nand riguardanti quei dati e le cancella senza portarsele dietro (formatta le pagine senza riscriverle da qualche altra parte).
Ne consegue che durate l'idle time il BGC farò proprio questo, aggiungendo un ulteriore layer di miglioramento alle performance.

2. Il TRIM ok... il BGC perchè no?

Se il SO non passa all'ssd i blocchi da considerare non validi il GC non può far nulla e di conseguenza non farà nulla neanche il BGC.
Ovviamente la sua implementazione è lato firmware.

3. Se così fosse, non si spiegherebbe il calo delle prestazioni... anche se meno aggressivo, il BGC renderebbe cmq l'SSD meno soggetto al degrado, invece dalle prove effettuate sui G2 ed altri modelli, si è riusciti a riprodurre facilmente mediante test lo "stato di degrado"...

Il calo di prestazioni si avrà sempre anche dov'è implementato il BGC.
Lo stesso BGC ha bisogno di un minimo di ore per essere efficace (Tony della OCZ, per le prime implementazioni, parlava addirittura di 19/24 ore utili per massimizzare i benefici del BGC).
Ripeto ancora una volta che attualemente il BGC porta comunque dei risvolti negativi relativi alla WA e aumento dei cicli di scrittura.

Alla fine resta sempre un problema: nessuno ha mia fornito dati e/o documenti sul funzionamento specifico e sulle varie ottimizazzioni adottate dai vari sviluppatori.
Si conosce solo il fondamento di tutte queste tecnologie.

[The_Saint]

Originariamente inviato da S3N

Il nesso sta nel avere ben in mente cosa è il TRIM.
Il SO passa un comado SATA all'SSD indicandogli gli LBA dei dati da cancellare.
A questo punto l'ssd nelle routine di GC prende le pagine delle nand riguardanti quei dati e le cancella senza portarsele dietro (formatta le pagine senza riscriverle da qualche altra parte).
Ne consegue che durate l'idle time il BGC farò proprio questo, aggiungendo un ulteriore layer di miglioramento alle performance.

Il TRIM viene eseguito subito, quindi il BGC eventualmente non troverà nulla da cancellare...

Originariamente inviato da S3N

Se il SO non passa all'ssd i blocchi da considerare non validi il GC non può far nulla e di conseguenza non farà nulla neanche il BGC.
Ovviamente la sua implementazione è lato firmware.

Il BGC può leggere le informazioni direttamente dal file-system (ovviamente deve supportarlo), in questo senso dicevo che è indipendente dal SO, non deve aspettare qualche cosa per potersi attivare da solo.

Originariamente inviato da S3N

Il calo di prestazioni si avrà sempre anche dov'è implementato il BGC.
Lo stesso BGC ha bisogno di un minimo di ore per essere efficace (Tony della OCZ, per le prime implementazioni, parlava addirittura di 19/24 ore utili per massimizzare i benefici del BGC).
Ripeto ancora una volta che attualemente il BGC porta comunque dei risvolti negativi relativi alla WA e aumento dei cicli di scrittura.

Su quest'ultima cosa siamo d'accordo, l'ho scritto anche io poco fa... il BGC attualmente implementato sugli Indilinx è una via di mezzo, ma a quanto pare sembra essere abbastanza efficace ed il tempo che necessita dipende da quanto è stato utilizzato l'SSD...

Originariamente inviato da S3N

Alla fine resta sempre un problema: nessuno ha mia fornito dati e/o documenti sul funzionamento specifico e sulle varie ottimizazzioni adottate dai vari sviluppatori.
Si conosce solo il fondamento di tutte queste tecnologie.

Questo è vero, anche se di alcuni controller (Intel G2/Indilinx, etc.) un po' di "reverse engineering" è stato fatto mediante test specifici, quindi qualche dato lo abbiamo.

[S3N]

Originariamente inviato da The_Saint

Il TRIM viene eseguito subito, quindi il BGC eventualmente non troverà nulla da cancellare... è

In realtà le cose non starebbero proprio così.
In fatti è possibile che dopo che il SO segna i blocchi da poter cancellare l'ssd può pianificare la loro cancellazione (-> link).
Questo significa che parte del processo di GC relativo potrebbe rientrare nelle routine di BGC.

Il BGC può leggere le informazioni direttamente dal file-system (ovviamente deve supportarlo), in questo senso dicevo che è indipendente dal SO, non deve aspettare qualche cosa per potersi attivare da solo.

L'attivazione è indipendente dal SO, ma senza SO non saprebbe mai su quali pagine/blocchi agire.

[enetec]

Originariamente inviato da S3N

Mi citi una fonte nella quale viene affermato che il GC di OCZ (e non il BGC) riesce ad interpretare gli LBA riguardanti i blocchi da considerare modificati all'interno delle pagine delle nand senza ricorrere al sistema operativo e basandosi solo sul tipo di file system?

Certo... http://www.anandtech.com/show/3997/o...ve-x2-review/4

cito testualmente (e non è l'unica fonte in tal senso cmq... poi se non è vero non so che dirti, non l'ho fatto io il firmware OCZ, altrimenti sarei sicuramente più ricco... )

"SSD controller manufacturers have avoided the TRIM issue by equipping drives with idle garbage collection. The principle behind idle garbage collection is simple. When the SSD controller detects a period of no activity, it can query the file system for available addresses, and then internally mark those addresses for cleaning."

Mi sembra estremamente chiaro come discorso. Ed il sito non mi pare uno di quelli che, solitamente, "conta balle"...

Originariamente inviato da S3N

Il nesso sta nel avere ben in mente cosa è il TRIM.
Il SO passa un comado SATA all'SSD indicandogli gli LBA dei dati da cancellare.
A questo punto l'ssd nelle routine di GC prende le pagine delle nand riguardanti quei dati e le cancella senza portarsele dietro (formatta le pagine senza riscriverle da qualche altra parte).
Ne consegue che durate l'idle time il BGC farò proprio questo, aggiungendo un ulteriore layer di miglioramento alle performance.

Se il SO non passa all'ssd i blocchi da considerare non validi il GC non può far nulla e di conseguenza non farà nulla neanche il BGC.Ovviamente la sua implementazione è lato firmware.

In base a quanto scritto sopra... parrebbe proprio di no...

Originariamente inviato da S3N

Il calo di prestazioni si avrà sempre anche dov'è implementato il BGC.
Lo stesso BGC ha bisogno di un minimo di ore per essere efficace (Tony della OCZ, per le prime implementazioni, parlava addirittura di 19/24 ore utili per massimizzare i benefici del BGC).
Ripeto ancora una volta che attualemente il BGC porta comunque dei risvolti negativi relativi alla WA e aumento dei cicli di scrittura.

Se le cose stanno come dicono sopra, non dovrebbe essere così (almeno con formattazioni "supportate" dal firmware ed una volta che gli stessi andranno a posto almeno...)

Originariamente inviato da S3N

Alla fine resta sempre un problema: nessuno ha mia fornito dati e/o documenti sul funzionamento specifico e sulle varie ottimizazzioni adottate dai vari sviluppatori.
Si conosce solo il fondamento di tutte queste tecnologie.

Senza voler minimamente andare in cerca di "polemica" (non avrei neanche il tempo per un eventuale "dibattito"...), qualcosina mi pare di aver portato.

Ovvio che, anche fra chi come me lavora professionalmente nel settore MA non è impiegato nello sviluppo del firmware da parte delle aziende interessate è un po' difficile che si possa trovare qualcuno in grado di fornire dati precisi sulle singole funzionalità degli algoritmi impiegati...

...e questo per due semplici motivi:

1) le case che li stanno sviluppando e che si fanno concorrenza anche e soprattutto su questi punti - oltre che sulle tecniche costruttive da un nanometro più o meno... - hanno tutto l'interesse a stare ben abbottonate in merito...

2) visto che un algoritmo "ideale" al momento pare che non ci sia, chi fosse in grado di svilupparlo, ripeto, sarebbe una persona ricca...

Detto questo, in base alle informazioni che ho reperito in giro, alla lettura attenta delle specifiche e di quanto dichiarato dalle case - almeno in via ufficiale - e sfruttando le basi delle mie conoscenze personali in materia penso di essermi fatto un'idea abbastanza, se non esatta, quanto meno "verosimile" della situazione attuale...

E, ripeto, senza una formalizzazione precisa dei protocolli da utilizzare da parte dell'OS nella comunicazione col driver del controller (SATA, AHCI, RAID o SAS che sia...) per passare i dati del TRIM verso il disco, lo stesso avrà sempre delle situazioni in cui non potrà funzionare...

Esattamente come quella parte ("intelligente"?) del GC (idle o backround che sia...) che va ad agire allo stesso modo del TRIM ma in modalità autonoma di cui si parlava sopra...

Senza una di queste due soluzioni in funzione, la parte "stupida" del GC (quella impiegata fin'ora da quasi tutti i produttori, tranne i più recenti OCZ da quanto mi risulta...) è evidente che non sarà mai così efficace da non introdurre un certo degrado nei tempi di scrittura dei drive SSD...

Questo almeno negli MLC, perché ad esempio i drive prodotti con memorie SLC pare risentano moolto meno di tale effetto (proprio per come funzionano le memorie al loro interno...). Peccato che costino mooolto di più...

[The_Saint]

Originariamente inviato da S3N

In realtà le cose non starebbero proprio così.
In fatti è possibile che dopo che il SO segna i blocchi da poter cancellare l'ssd può pianificare la loro cancellazione (-> link).
Questo significa che parte del processo di GC relativo potrebbe rientrare nelle routine di BGC.

Questo è vero, l'operazione di erase della cella è pianificato ma potrebbe essere eseguito in un altro momento, ora ho capito cosa intendevi dire... però la tua affermazione "senza il BGC il Trim sarebbe molto meno efficace" dovrebbe essere il contrario, ovvero "il BCG è meno efficace senza l'ausilio del TRIM"... anche perchè tutti gli SSD che hanno il TRIM, hanno anche un GC che lavora in background, ma la differenza è che i dati su cui lavora sono solo quelli appunto forniti dal TRIM e basta, non hanno routine che provvedono a cercare da sole le celle da ripulire...

Originariamente inviato da S3N

L'attivazione è indipendente dal SO, ma senza SO non saprebbe mai su quali pagine/blocchi agire.

Questo è ovvio, senza SO non c'è nemmeno bisogno di TRIM o GC!

[S3N]

Originariamente inviato da The_Saint

Questo è vero, l'operazione di erase della cella è pianificato ma potrebbe essere eseguito in un altro momento, ora ho capito cosa intendevi dire... però la tua affermazione "senza il BGC il Trim sarebbe molto meno efficace" dovrebbe essere il contrario, ovvero "il BCG è meno efficace senza l'ausilio del TRIM"... anche perchè tutti gli SSD che hanno il TRIM, hanno anche un GC che lavora in background, ma la differenza è che i dati su cui lavora sono solo quelli appunto forniti dal TRIM e basta, non hanno routine che provvedono a cercare da sole le celle da ripulire...

Questo è ovvio, senza SO non c'è nemmeno bisogno di TRIM o GC!

Ok alla fine ci siamo capiti.

Solo un appunto.
Il BGC lavora sia su pagine/blocchi modificati/sovrascritti che su quelli cancellati.
Ecco perchè dicevo che con il TRIM è più efficace.
Perchè sui blocchi cancellati ("trimmati") ha meno passaggi da compiere: in pratica effettua solo un erase (es. cancellazione di un blocco intero) oppure, rispetto al caso di dati modificati/sovrascritti, un minor numero di riscritture.

Per il funzionamento generale di queste tecnologie abbiamo capito, nei nostri limiti, comunque come funzionano.

Per rispondere a enetec:
diciamo la stessa cosa, solo che quello che volevo far notare è che gli LBA legati ai PBA da qualche parte il GC deve pur prenderli.
Ed è proprio il SO che glieli fornisce.
Tutto quì.

[enetec]

Originariamente inviato da S3N

Ok alla fine ci siamo capiti.
...
Per rispondere a enetec:
diciamo la stessa cosa, solo che quello che volevo far notare è che gli LBA legati ai PBA da qualche parte il GC deve pur prenderli.
Ed è proprio il SO che glieli fornisce.
Tutto quì.

Esatto. Direttamente (TRIM) o indirettamente (idle GC OCZ) che sia.

Il punto è se sarebbe meglio cercare di investire risorse per cercare di aumentare le possibilità di applicazione del TRIM o se cercare nuovi metodi/algoritmi per rendere più efficace il GC.

O, infine, se migliorare la tecnologia costruttiva per risolvere il problema alla radice.

Oppure, ad esempio, l'adozione di una discreta quantità di cache a bordo dei dischi tale da "mascherare" la reale lentezza di scrittura delle celle MLC non trimmate... (magari col firmware del disco che la adotta come area "di parcheggio temporaneo" dei dati SOLO quando si trova a scrivere su quelle non trimmate, così da ottenere risultati interessanti anche con minori quantità di cache... )

Le soluzione, volendo, si trovano sempre. Diamo tempo al tempo...

Anche perché, cmq, una SSD "rallentata al massimo" da celle non trimmate, rimane sempre nettamente più veloce anche in scrittura di un disco tradizionale, non dimentichiamolo...

Qui si parla se è meglio il caviale o il salmone, ma fino a ieri si mangiava mortadella!

[tirannosaurorex]

Originariamente inviato da jined

volevo anche ricordare, che più scende la scala di nanometri, e più si riducono i cicli di scrittura

Esatto.

Negli SSD della Samsung le NAND sono a 30 nanometri per cui i cicli di scrittura sono più ridotti rispetto agli SSD Intel e filo-Intel.

Approfitto anche per precisare che il Bacground Garbage Collection è stato introdotto da Samsung nei propri SSD nel 2008 essendosi accorti che il semplice Garbage Collection non funzionava.

Il semplice Garbage Collection invece è a tutt' oggi implementato negli SSD Intel e filo-Intel che per funzionare a dovere devono avvalersi del TRIM di W7 via software escludendo però configurazioni degli SSD in RAID dove il TRIM non funzia.

[The_Saint]

Originariamente inviato da tirannosaurorex

Negli SSD della Samsung le NAND sono a 30 nanometri per cui i cicli di scrittura sono più ridotti rispetto agli SSD Intel e filo-Intel.

Mi sa che non hai capito... avere meno cicli di scrittura vuol dire che la cella NAND durerà meno, quindi non è una cosa positiva!
Ad esempio i primi SSD con NAND a 50nm erano garantiti per 10.000 cicli di scrittura, quelle a 35nm per 5.000...

Originariamente inviato da tirannosaurorex

Approfitto anche per precisare che il Bacground Garbage Collection è stato introdotto da Samsung nei propri SSD nel 2008 essendosi accorti che il semplice Garbage Collection non funzionava.

Quando Samsung si è accorta di questo, gli SSD con controller Indilinx avevano già l'idle garbage collection.

Originariamente inviato da tirannosaurorex

Il semplice Garbage Collection invece è a tutt' oggi implementato negli SSD Intel e filo-Intel che per funzionare a dovere devono avvalersi del TRIM di W7 via software escludendo però configurazioni degli SSD in RAID dove il TRIM non funzia.

Questo è risaputo... ma cosa intendi per SSD filo-Intel? Il controller Intel è usato solo negli SSD Intel.


Sono sempre in attesa dei tuoi test sul BGC Samsung... quando li posti?

[tirannosaurorex]

Ci tengo a precisare che ho una grande ammirazione per la politica commerciale della Intel perché sanno come far quattrini a palate e lo si può riscontrare dai dati del fatturato in aumento nel terzo trimestre di quest' anno.

Molto probabilmente questo è dovuto proprio al fatto di non aver scelto la strada di Samsung di implementare nel controller dell' SSD il Background Garbage Collection ma di scegliere il TRIM implementato nel sistema operativo W7 ... questo chiaramente ha incentivato le vendite per Microsoft perché chi si comprava un SSD Intel o filo-Intel doveva poi per non perdere le prestazioni dell' SSD comprarsi il sistema operativo W7 ma d' altro canto una volta messo nel proprio pc un sistema operativo come W7 che occupa 19GB di spazio sull' SSD qualcuno si sarà accorto che la RAM non era più sufficente e che neanche il processore ce la faceva a trascinarlo, per cui scheda madre nuova + CPU nuova + 8 GB di RAM e la Intel incassa.

Chiaramente non tutti poi si comprano la scheda madre Intel e il processore Intel e non tutti utilizzano W7 ma una buona percentuale SI e il fatturato della Intel cresce come dimostrano i dati.

Questo è un esempio tipico di come le aziende americane lavorino in sinergia per risollevare l' economia ..... mica come le nostre

Che grandi che sono le aziende americane, di un' astuzia e una furbizia uniche

[The_Saint]

Originariamente inviato da tirannosaurorex

... Molto probabilmente questo è dovuto proprio al fatto di non aver scelto la strada di Samsung di implementare nel controller dell' SSD il Background Garbage Collection ma di scegliere il TRIM implementato nel sistema operativo W7 ... questo chiaramente ha incentivato le vendite per Microsoft perché chi si comprava un SSD Intel o filo-Intel doveva poi per non perdere le prestazioni dell' SSD comprarsi il sistema operativo W7
...
Questo è un esempio tipico di come le aziende americane lavorino in sinergia per risollevare l' economia ..... mica come le nostre

Non è questo il caso, il tuo ragionamento non è corretto... hai tralasciato il fatto Intel insieme al supporto per il TRIM ha rilasciato anche una utility chiamata "Intel SSD Tool" che esegue manualmente il TRIM nei sistemi operativi come Windows XP che non lo supportano nativamente... quindi non c'era nessun bisogno di passare a Win7...

[The_Saint]

Originariamente inviato da enetec

...Oppure, ad esempio, l'adozione di una discreta quantità di cache a bordo dei dischi tale da "mascherare" la reale lentezza di scrittura delle celle MLC non trimmate... (magari col firmware del disco che la adotta come area "di parcheggio temporaneo" dei dati SOLO quando si trova a scrivere su quelle non trimmate, così da ottenere risultati interessanti anche con minori quantità di cache... )
Le soluzione, volendo, si trovano sempre. Diamo tempo al tempo...

L'utilizzo di una cache grande crea svariati problemi, fra i quali il consumo, il costo aggiuntivo (intendo costo di produzione) ed il fatto che per evitare la perdita di dati in caso di cali/interruzione della tensione, va implementato anche un sistema che garantisca il tempo di scrivere i dati nelle NAND prima di spegnersi (come un piccolo accumulatore o addirittura una batteria tampone)... è per questo che ad esempio il controller SandForce non integra nessuna cache, ha solo un buffer interno al chip stesso del controller.
Cmq le soluzioni adottate da SF, anche se non perfette, sono molto buone ed innovative rispetto alla concorrenza... vediamo cosa tirano fuori con la nuova serie di controller SF-2000.