View Single Post
Old 17-04-2014, 14:58   #3793
s12a
Senior Member
 
L'Avatar di s12a
 
Iscritto dal: Jan 2008
Messaggi: 11073
:

Quote:
Originariamente inviato da s12a
Per l'usura del drive non contano tanto i GB/giorno di scritture host (ossia richieste dal sistema operativo/utente), piuttosto quanto effettivamente essi vanno a movimentare dati nelle sue celle di memoria. Questo dipende dalla write amplification, la quale varia a seconda del proprio utilizzo e tipo di dati con cui si ha a che fare. Per fare un esempio, 25 GB/gg con write amplification di 2x (25 * 2 = 50 GB) sono meno usuranti di 6 GB/gg con write amplification di 20x (6 * 20 = 120 GB).

Poi tocca fare considerazioni pratiche, in ogni caso. Se nonostante tutto pur considerando una write amplification elevata (ad esempio magari con usi "spot" del computer, ossia accenderlo brevemente solo al momento del bisogno - tendono ad aumentarla a prescindere dal tipo di dati movimentati) la prospettiva è comunque di 8-10 anni per arrivare al 100% di usura nominale, non è che ci sia da disperarsi.

Il problema può insorgere quando si hanno contemporaneamente sia write amplification elevata (mettiamo 15x), sia un numero di scritture host giornaliere relativamente elevato, almeno per usi home (esempio 25 GB/giorno. In assoluto sono pochi però). In questo esempio avremmo 25 x 15 = 375 GB al giorno di scritture movimentate effettivamente sulle memorie NAND, che usurerebbero un SSD da 256 GB e memorie MLC (2bit per cella, 3000 cicli P/E) in poco più di 5 anni.

* * *

La write amplification può aumentare in diversi modi. Uno meno noto è che effettuare scritture troppo piccole troppo spesso può in certi casi aumentarla considerevolmente. Negli SSD infatti si può scrivere solo a colpi di "pagine" che hanno una certa dimensione minima e non si possono sovrascrivere se non previa cancellazione. La cancellazione può a sua volta avvenire solo a macro blocchi di pagine. Il controller di gestione dell'SSD si occupa internamente di gestire questa complicazione, per quello che può, e si può immaginare quanto gravoso sia il suo compito, dato che deve evitare di usurare le memorie NAND il più possibile, con questi paletti.

I sistemi operativi moderni vengono fortunatamente parzialmente incontro a queste esigenze (in realtà soprattutto per questioni prestazionali) inglobando le scritture da effettuare in un certo buffer (una sorta di "serbatoio" di dati da scrivere), che viene "scaricato" nel drive ad intervalli regolari o quando si riempe (a meno che i programmi non effettuino bypass esplicito della cosa richiedendo uno "scaricamento" immediato - denominato inglese "flushing" - dei dati scritti).

In generale, più dati contemporaneamente vengono trasferiti per scrittura effettuata, meno spreco avviene nella programmazione delle memorie. Nel caso del popolare Samsung 840 Pro il suo controller può scrivere sulle memorie solo a gruppi di 8 kB per volta, e cancellare a gruppi di 1024 kB.

(implicazione diretta della cosa: se dobbiamo scrivere solo un dato da 400 byte e l'SSD non trova altri dati da agglomerare insieme - situazione difficile comunque con un uso normale del sistema operativo in cui ci sono sempre dati da scrivere il write buffer di sistema menzionato poc'anzi - la write amplification per quella scrittura sarà immediatamente di almeno 8192 byte / 400 byte = 20.5x).

Da me, in questo momento preciso il processo di Firefox (che è singolo, ma il più esoso in termini di scritture fra i processi in lista che ho) ha effettuato 7,895,625,000 byte in 804,718 scritture. Questo equivale a 9811 byte/scrittura in media, quindi dando per assunto che ci sia solo questo programma ad effettuare queste scritture, sarei sopra la dimensione minima dei blocchi di programmazione delle memorie NAND dell'SSD. Ma visto che 9811 byte in un blocco da 8 kB non entrano, richiedono due blocchi, quindi 16 kB, e perciò la write amplification per queste scritture (sempre assumendo un drive vuoto, ossia che non richiedano lo spostamento - quindi cancellazione - di altri dati per liberare blocchi in scrittura) sarebbe in media di 16384 / 9811 = 1.67x. Questo sempre ipotizzando che non ci siano altri dati da scrivere nello stesso periodo di tempo, cosa improbabile, ma non impossibile.

* * *

Analizzare i dati SMART del proprio drive, specie se fornisce indicazioni dirette sulle scritture effettuate sulle memorie NAND può aiutare a capire meglio come funzionano e sono gestiti gli ultimi SSD in generale. Ad esempio io sto scoprendo un po' di cose tecniche interessanti sul Sandisk Extreme II 480GB che ho recentemente preso come upgrade al mio precedente Samsung 840 250GB. Ho provato a monitorarlo per i primi giorni di attività. Osservare in particolar modo l'ultima colonna, rappresentante la write amplification calcolata dall'ultima rilevazione effettuata:


http://i57.tinypic.com/2exui5w.png

Finché il drive era nuovo, con tutte le celle vergini (e probabilmente anche per via dei trasferimenti tendenzialmente sequenziali e random a blocchi di 4kB o superiori), la write amplification è rimasta molto vicina ad 1.0x. Quando ho iniziato ad usarlo normalmente come al solito (browser, giochi, download ecc) e soprattutto, una volta che tutte le celle hanno ricevuto almeno una scrittura, sembra che la write amplification sia aumentata a circa 3.5x.

Il wear leveling su questo drive sembra a prima vista essere abbastanza meno efficiente di quello del Samsung 840 250 GB che usavo in precedenza, che si attestava a circa 1.5x in condizioni di normale utilizzo. Tecnicamente parlando, differenze firmware a parte nella gestione interna, probabilmente incide anche il fatto che sulle memorie NAND MLC 19nm Sandisk di questo drive l'erase block size è di ben 4 MB, mentre sulle Samsung TLC dell'840 è di 1.5 MB. In altre parole per effettuare il wear leveling il Sandisk sarà costretto a spostare più dati insieme. (La cosa sembra avere riscontri nella pratica.

Questo per dire che le memorie TLC (3 bit per cella) montate nei Samsung 840/840 EVO avranno sì una durata sulla carta tre volte inferiore alle normali MLC (2 bit per cella), ma se il wear leveling è almeno il doppio più efficiente a parità di utilizzo, nella pratica la differenza in tal senso è assai più sottile.

La tendenza dei produttori infatti, per diminuire i costi a parità di capienza è oltre quella di rimpicciolire il processo produttivo (ossia fisicamente la dimensione delle celle di memoria) od aumentare il numero di bit per cella, è anche quella di aumentare la dimensione delle pagine di programmazione (in inglese: program page size) ed quella dei blocchi di cancellazione (in inglese: erase block size). Fino a qualche anno fa la maggior parte degli SSD aveva un program page size di 4 kB, mentre un erase block size da 256 kB-1MB. La cosa era controbilanciata dal wear leveling in genere meno efficiente.

Oggi la maggior parte delle memorie degli SSD con processo produttivo a 1x-2x nm ha un page size di 8 kB, incluso il Sandisk Extreme II che ho preso recentemente. L'erase block size è più variabile, ma oramai si va sui 2MB in media. Da notare che più aumenta la dimensione dei blocchi di programmazione e cancellazione, più aumentano anche i tempi fisici per effettuare tali operazioni, cosa che comunque nuove tecniche e miglioramenti in altri aspetti cercano di contenere.

Curiosità: stando ai dati che sono riuscito a reperire in giro, il Crucial M500 ha memorie MLC da pagine da 16 kB ed erase block da ben 8 MB. E' probabilmente anche per questo che costa meno della media nonostante le MLC. Il wear leveling deve essere ben studiato perché altrimenti la write amplification controbilancerebbe la maggiore durata intrinsica rispetto alle memorie TLC (e magari ad un certo punto uscirà fuori che alla fin fine non ci sono vantaggi effettivi rispetto alle TLC Samsung in termini di durata in terabyte scritti).
__________________
CPU Intel i7-12700K ~ Cooler Noctua NH-D15S ~ Motherboard MSI PRO Z690-A WIFI DDR4 ~ RAM Corsair Vengeance LPX 64 GB DDR4-3600
GPU MSI GeForce RTX 3090 GAMING X TRIO 24G ~ SSD SK hynix Platinum P41 2TB + Samsung 990 Pro 4TB
PSU Corsair RM850x ~ Case Fractal Design Define C ~ Display Dell U2412M (A00) + NEC EA231WMi ~ OS
s12a è offline   Rispondi citando il messaggio o parte di esso