Quote:
Originariamente inviato da AceGranger
Remember what TRIM does. The TRIM command simply tells the controller what LBAs are no longer needed by the OS. It doesn't physically remove data from the SSD, it just tells the controller that it can remove the aforementioned data at its own convenience and in accordance with its own algorithms.
|
Ciao, questa è la parte interessante.
Viene spiegato che il controller può scegliere di non onorare subito il comando TRIM, ma di aspettare, proprio nel tentativo di ridurre la write amplification.
Più in generale, qualsiasi operazione comporti una cancellazione fisica della flash (TRIM, GC, ecc.) ha come effetto collaterale quello di bruciare cicli _dell'intera pagina/blocco_ comportando quindi un aumento della write amplification.
C'è una scappatoia: se tutta la pagina flash contiene dati da cancellare, tecnicamente non c'è nessun write amplification (su quella pagina). E' per questo motivo che il controller può ritardare l'effetto del TRIM: aspetta che tutta la pagina flash sia da riprogrammare.
Quote:
|
l'unica parte in cui parla della write amplification e cancellazione dati è riferita solo al GC aggressivo, e presumo che si riferisca a quello degli Indilinx, che è stato anche modificato nel tempo, visto che nei vecchi firmware era molto aggressivo.
|
Si, i primi firmware Indilix erano molto aggressivi col GC (almeno a quanto riportato dai siti che gli hanno testati). I Toshiba lo erano ancora di più: praticamente, ogni volta che si eliminava un file, il GC interveniva e cancellava la flash, comportandosi come un TRIM. Proprio per questo Anand faceva notare che i Mac, il cui s.o. Mac OS X non supporta(va?) ancora il TRIM, spesso montavano disci SSD Toshiba.
Ciao.
