SSD: thread generale e consigli per gli acquisti

[giovanni69]

@Black: mi permetto di suggerirti di aggiornare più spesso la prima pagina con i contributi che posti, indicizzando appunto i tuoi messaggi, quelli di Liupen ed altri, con appositi sublinks che portino ai singoli post.


Tra una decina di pagine questi post di recente interesse (ed altrettanti dei mesi scorsi) saranno sepolti e difficilmente rintracciabili a distanza di mesi a o anni. E sarebbe un vero peccato.

Grazie.

[Black (Wooden Law)]

Originariamente inviato da giovanni69

@Black: mi permetto di suggerirti di aggiornare più spesso la prima pagina con i contributi che posti, indicizzando appunto i tuoi messaggi, quelli di Liupen ed altri, con appositi sublinks che portino ai singoli post.


Tra una decina di pagine questi post di recente interesse (ed altrettanti dei mesi scorsi) saranno sepolti e difficilmente rintracciabili a distanza di mesi a o anni. E sarebbe un vero peccato.

Grazie.

Io e Liupen parliamo quasi sempre in modo molto tecnico, ho paura che mettendo tanti dei nostri commenti in prima pagina diventino inutili perché di difficile comprensione. Aggiungere il commento su AWT ha sicuramente senso visto che è un concetto di facile comprensione e inerente alla cache SLC, ma aggiungere i commenti sull'architetture delle NAND flash secondo me non hanno senso o sarebbe visti e capiti da pochi.

[Black (Wooden Law)]

@frafelix eccoci: https://www.techpowerup.com/review/crucial-t710-2-tb/.
Come volevasi dimostrare, SM2508 con B68S, versione del 4600 non OEM.

La cache SLC nel taglio da 2TB è di 368GB secondo TPU, le performance in direct-to-TLC sono da poco meno di 4.000 MB/s e fa del folding (circa 2.000 MB/s). Praticamente lo stesso comportamento dell'SN8100 solo che quest'ultimo c'ha una cache SLC molto più grande, 200+GB. Come temperature, il TT sembra partire dagli 85 °C in su e sotto stress, senza dissipatore, l'SSD fa poco meno di 100 °C.

[megthebest]

Originariamente inviato da Black (Wooden Law)

. Come temperature, il TT sembra partire dagli 85 °C in su e sotto stress, senza dissipatore, l'SSD fa poco meno di 100 °C.

[Nicodemo Timoteo Taddeo]

Originariamente inviato da megthebest

Sì dispositivi da notebook e miniPC

[@Liupen]

Originariamente inviato da Black (Wooden Law)

'Sta parte non l'ho capita neanch'io (mi sembrano parole a caso...) ma l'unica cosa che ho capito è che hanno ridotto la dimensione dei page buffer (nella figura si vede che quelli sotto sono più piccoli) e il passo con le BL, cioè mi sembra che abbiano ridotto il numero di PB per BL. Prima c'erano 16 PB per 16 BL mentre ora 6 PB per 6 BL... Nel parallelo sembra che non ci sia differenza ma boh, io così l'ho intesa. Dubito che abbia capito correttamente ma che ci possiamo fare, Micron non vuole dare spiegazioni più decenti...

Hahaha! Si, sembrano parole a caso!

La frase tradotta è questa:
A. Scalabilità dell'area per consentire il parallelismo dei piani: buffer di pagina 6BL
Per supportare un'elevata larghezza di banda del sistema, la tecnologia G9 è stata progettata mantenendo l'architettura a 6 piani del G8 da 1 TB. A causa della significativa riduzione del 30% delle dimensioni del die da G8 da 1 TB a G9, l'architettura del buffer di pagina ha dovuto essere adattata a un passo di 6 bitline. È stata ottenuta una riduzione del 50% dell'area del buffer di pagina rispetto a G8. Ciò è stato possibile introducendo un processo di raddoppio del passo del metallo per il livello di interconnessione, nonché un'attenta ottimizzazione del dispositivo CMOS per mantenere le specifiche di corrente di standby nonostante la significativa riduzione della lunghezza e della larghezza del transistor del buffer di pagina.

Sono d'accordo con te. Destrutturando il senso di quanto detto da loro nel testo:

1 - È stata ottenuta una riduzione del 50% dell'area del buffer di pagina rispetto a G8 (quindi riduzione del PB)
2 - A causa della significativa riduzione del 30% delle dimensioni del die da G8 da 1 TB a G9, l'architettura del buffer di pagina ha dovuto essere adattata a un passo di 6 bitline. (Prima c'erano 16 PB per 16 BL mentre ora 6 PB per 6 BL)

Quindi dice, G9 è più piccola di G8, il buffer di pagina diventa anche lui ovviamente più piccolo (sarebbe il collegamento tra cella e CMOS che raccoglie i dati per Pagina (poi ci sarà qualcosa che farà da buffer del blocco fisico)... comunque: ridotta la cella-->ridotto il circuito.

Ora, tornando al testo:

3 - per mantenere le specifiche di corrente di standby nonostante la significativa riduzione della lunghezza e della larghezza del transistor del buffer di pagina (quindi questo causa la riduzione delle celle), è stato introdotto un processo di raddoppio del passo del metallo per il livello di interconnessione, nonché un'attenta ottimizzazione del dispositivo CMOS

praticamente "supercazzola".
Non dice che dove ora stanno 2 x 6BL (e relativi buffer) prima c'era 1x 16 BL... e anche se fosse non sarebbe un raddoppio
Dov'è sto raddoppio e che c'entra la figura 5?!!

Originariamente inviato da Black (Wooden Law)

Micron dice di aver diviso in due le WL e che ciò consegue ad una duplicazione dei driver delle stringhe (che non so cosa siano). Guarda (a) di Figura 8: quella è teoricamente una classica NAND flash 3D (anche se ora dice che nei modelli recenti le WL sono divise a metà...). Le WL sono intere e quella "cosa" a destra verde chiaro è appunto il driver delle stringhe. (b) è una classica NAND flash 3D ma con le WL tagliate. Se noti, in mezzo alla figura ci sono i due driver delle stringhe. Visto che hanno tagliato le WL in due hanno dovuto mettere due driver per ogni blocco di WL tagliato: i driver si sono effettivamente duplicati.
Questo, quindi, penso che sia un problema da mitigare e l'hanno risolto "collegando" i due blocchi di WL tagliati tramite delle scale bidirezionali e usando soltanto un driver di stringhe per entrambi i blocchi.

Il driver di stringa è il circuito elettrico che da tensione alla WL. Dice che dividendo in due le WL si duplica anche il circuito che le controlla.

Con ciò rimane che non ne il fatto che si dividano le WL ne l'utilizzo della struttura a scala bidirezionale, siano novità tirate fuori da micron nelle G9; diciamo che la verità è quella che, addensando le celle, e per migliorare le prestazioni, hanno utilizzato le stesse soluzioni che adottano già altri ...per non dire tutti.

Originariamente inviato da Black (Wooden Law)

La differenza con la solita architettura a scala è che questa delle G9 è bidirezionale e mi sembra che ha senso visto che spezzi in due le WL. Qui le WL non sono divise in due e non esistono scale bidirezionali.

Bidirezionale si riferisce alla "scala" ovvero alla struttura che alterna WL BL e Control gate. Ti linko un immagine delle BICS 8 che abbiamo visto già



nota come la scala è doppia (degrada in un senso e nell'altro per permettere il collegamento agevole delle WL alla parte CMOS).


Comincio a pensare che forse quando nel testo si dice:
La scala bidirezionale (SC) ha risolto il compromesso tra latenza di lettura, energia di lettura per bit ed efficienza dell'array
Micron abbia solo introdotto nelle G9 la SC; cosa che forse prima non faceva a dispetto di tutti gli altri produttori.

Originariamente inviato da Black (Wooden Law)

EDIT: anche la WL di molibdeno al posto di tungsteno non è nulla di nuovo: https://www.kioxia.com/en-jp/rd/tech...topics-71.html.

Non vorrei dirlo ma... Micron nelle G9 non ci ha proprio messo niente di suo.

Originariamente inviato da giovanni69

@Black: mi permetto di suggerirti di aggiornare più spesso la prima pagina con i contributi che posti, indicizzando appunto i tuoi messaggi, quelli di Liupen ed altri, con appositi sublinks che portino ai singoli post.


Tra una decina di pagine questi post di recente interesse (ed altrettanti dei mesi scorsi) saranno sepolti e difficilmente rintracciabili a distanza di mesi a o anni. E sarebbe un vero peccato.

Grazie.

Rimane un argomento settoriale quello della struttura delle 3D Nand.
Molti lo troverebbero anche noioso.

Io proporrei questi.

https://www.youtube.com/watch?v=ANHzVOiUwGI

In cui si parta dall'attuale aspetto delle nand 3d (escluse le ultimissime che hanno il CMOS interamente sopra).
Il video evolve come se si dovessero fabbricare delle nand 3d, per arrivare nell'ultimo assemblaggio a costruire le relative bitline e control gate.


I questo

https://youtu.be/4BZpT_uI7N4?t=21

si può dire che l'evoluzione continua... dalla 96L alla 2xx layer si possono seguire le principali novità:

- nuovo sistema per realizzare i fori con la crio incisione a livello ionico
- l'utilizzo dell'impilamento degli stack per realizzare le 2xxL
- il problema della flessione strutturale da risolvere
- il bounding con il CMOS (cioè la parte che controlla elettricamente le celle e che può essere realizzata a se stante e poi solo successivamente "incollata").
- persino il tungsteno sostituito dal molibdeno
- ed il futuro bounding array, cioè l'incollaggio di stack su stack (oltre che al CMOS)

Infine

https://www.youtube.com/watch?v=cdHPHsJAa8Y
https://www.youtube.com/watch?v=2nyNCblXIl8

infarinatura di come viene usata la memorizzazione dei dati nell'ssd

[Black (Wooden Law)]

Originariamente inviato da @Liupen

Non vorrei dirlo ma... Micron nelle G9 non ci ha proprio messo niente di suo.

Decisamente Liupen, ne son convinto anch'io. Hanno buttato tanti concetti insieme usando termini un po' a casaccio e boh, hanno parlato di novità che tanto "novità" non sono. Comunque sono delle buone NAND flash, per l'amor del cielo, ma il fatto che le BiCS8 siano più diffuse nei Gen5 mi fa pensare che anche i produttori si siano resi conto che Kioxia sia più avanti degli altri produttori NAND flash; se vedi, gli SSD con E31T son tutti quanti con BiCS8, non B68S.

Originariamente inviato da @Liupen

Rimane un argomento settoriale quello della struttura delle 3D Nand.
Molti lo troverebbero anche noioso.

Io proporrei questi.

https://www.youtube.com/watch?v=ANHzVOiUwGI

In cui si parta dall'attuale aspetto delle nand 3d (escluse le ultimissime che hanno il CMOS interamente sopra).
Il video evolve come se si dovessero fabbricare delle nand 3d, per arrivare nell'ultimo assemblaggio a costruire le relative bitline e control gate.


I questo

https://youtu.be/4BZpT_uI7N4?t=21

si può dire che l'evoluzione continua... dalla 96L alla 2xx layer si possono seguire le principali novità:

- nuovo sistema per realizzare i fori con la crio incisione a livello ionico
- l'utilizzo dell'impilamento degli stack per realizzare le 2xxL
- il problema della flessione strutturale da risolvere
- il bounding con il CMOS (cioè la parte che controlla elettricamente le celle e che può essere realizzata a se stante e poi solo successivamente "incollata").
- persino il tungsteno sostituito dal molibdeno
- ed il futuro bounding array, cioè l'incollaggio di stack su stack (oltre che al CMOS)

Infine

https://www.youtube.com/watch?v=cdHPHsJAa8Y
https://www.youtube.com/watch?v=2nyNCblXIl8

infarinatura di come viene usata la memorizzazione dei dati nell'ssd

Grazie delle fonti Liupen.

Sotto a "link utili" stavo pensando di aggiungere tutte le fonti che uso per studiare e ripassare come corsi universitari su YouTube, libri, ecc.

[Black (Wooden Law)]

Originariamente inviato da @Liupen

3 - per mantenere le specifiche di corrente di standby nonostante la significativa riduzione della lunghezza e della larghezza del transistor del buffer di pagina (quindi questo causa la riduzione delle celle), è stato introdotto un processo di raddoppio del passo del metallo per il livello di interconnessione, nonché un'attenta ottimizzazione del dispositivo CMOS

L'unica cosa che c'entra con le NAND flash di "metallo per il livello di interconnessione" sono i contatti che si usano per collegare le bitline alle celle NAND flash. Guarda questa foto e guarda "Contact: Tungsten metal fill".

Dal momento che questi contatti fungono da interconnessioni nell'array NAND flash (e penso che si stendino pure allo strato CMOS), non è che stanno dicendo "a seguito di una riduzione dimensionale e quantitativa dei PB, abbiamo dovuto raddoppiare le interconnessioni di metallo ottimizzando la parte CMOS"? ha senso secondo te? Perché se accorci il numero di PB automaticamente aumenti la distanza tra le interconnessioni in metallo e i PB stessi, quindi per coprire questa distanza maggiorata aumenti il passo delle interconnessioni.

[frafelix]

Originariamente inviato da Black (Wooden Law)

@frafelix eccoci: https://www.techpowerup.com/review/crucial-t710-2-tb/.
Come volevasi dimostrare, SM2508 con B68S, versione del 4600 non OEM.

La cache SLC nel taglio da 2TB è di 368GB secondo TPU, le performance in direct-to-TLC sono da poco meno di 4.000 MB/s e fa del folding (circa 2.000 MB/s). Praticamente lo stesso comportamento dell'SN8100 solo che quest'ultimo c'ha una cache SLC molto più grande, 200+GB. Come temperature, il TT sembra partire dagli 85 °C in su e sotto stress, senza dissipatore, l'SSD fa poco meno di 100 °C.

Quindi non spodesta ancora l'sn8100, ma se costasse come il t705 sarebbe un buon concorrente per il prezzo. Se costa 20 euro in meno ha poco senso, se non per avere concorrenza! Grazie per la segnalazione

[Black (Wooden Law)]

Questo lo trovo interessante riguardo alla discussione che abbiamo avuto io, @Liupen, Sbaffo e Frafelix sull'SSD nel PC Mac di Frafelix: Solid-State Drive Over-Provisioning Technology and its Impact on the Ability to Erase Individual Files.

il mashing dei dati su un solid-state drive usando il comando TRIM non è sempre efficace. Per esempio, [7] ha dimostrato che software di recupero dei dati eliminati su alcuni drive SSD, anche con i comandi TRIM o Deallocati abilitati, può essere efficace, specialmente per piccoli file. Inoltre, è stato dimostrato in [4] che anche con un comando TRIM riuscito i dati eliminati possono rimane sul drive per molto tempo fino a quando il garbage collector non li raggiunge.

Qui sembra parlare indirettamente di un secure erase con dati randomici, cioè tutti 1:

Il secondo approccio è basato sulla cancellazione di informazioni al livello dei dati di blocco dei drive SSD (cambiando ogni bit di questo blocco usato per memorizzare i dati non eliminati da zero a uno), il cui utilizzo, tuttavia, porta ad un aumento del consumo energetico, delle performance ridotte e ad una riduzione del servizio di vita dell'SSD dal momento che ogni blocco può sopportare una limitata quantità di cicli di scrittura/cancellazione. I risultati di degli esperimenti condotti dagli autori [5] hanno mostrato una sufficiente efficacia del secondo approccio e una leggere diminuzione delle performance del drive SSD. Tuttavia, è emerso che il suo utilizzo pratico richiede una modifica significativa del firmware dell'unità SSD, il che rende difficile il suo utilizzo.

Qui le due parti non tradotte. [4] è Reliably Erasing Data From Flash-Based Solid State Drives, [5] è ErasuCrypto: A Lightweight Secure Data Deletion Scheme for Solid State Drives, [7] è Deleted Data Recovery on Solid-State Drives by Software Based Methods.

Le conclusioni dello studio sono che divide in tre gruppi i metodi per la cancellazione dei file negli SSD:
1. metodi che richiedono la modifica del firmware e che non sono utilizzabili nella pratica perché SSD di diversi produttori con diversi chip NAND flash e diversi "algoritmi di funzionamento del controller interno" sono installati su computer protetti;
2. metodi tramite dei software che spesso non spesso non sono sufficientemente affidabili anche per la parte del recupero;
3. tecnologie di cancellazione dei dati tramite crittografia che cancellano l'intero SSD e non i singoli file e richiedono modifiche al firmware.

In quanto all'OP, dice che rende inefficace il "mashing" dei dati nello spazio libero dell'SSD, che parte dello spazio degli indirizzi non è accessibile ai software e che non è possibile cancellare i dati senza interferire con il firmware dell'SSD o usando i software dei produttori di SSD. In questo caso le cancellazioni tramite crittografia sono utili.
-------------------------------------------------------
Anche lo studio [7], Deleted Data Recovery on Solid-State Drives by Software Based Methods è rilevante alla discussione.

Hanno testato (su Windows 10 Enterprise 21H1) 2 870 EVO, 8 860 EVO e 8 BX500 e altri SSD di cui ci interessa relativamente con 3 testi di file da rispettivamente 250B, 250kB e 25MB. I risultati sono che i file da 250B non sono stati eliminati dal garbage collection perché Master File Table (MFT) di NTFS contiene i file da meno di 700B e l'eliminazione di file piccoli non porta a far azionare il TRIM perché le modifiche vengono effettuate nella MFT. Per quanto concerne i file da 250kB e 25MB, tutti i garbage collection degli SSD ci hanno messo dai 5 ai 15 secondi per fare il loro (tranne per l'Intel 760p da 256GB dove ci ha messo dai 6,2 secondi ai 4,22 minuti).

Le tempistiche dell'evento di garbage collection che cancella i dati irrilevanti del file cancellato sono mostrate nella Fig. 1. Il file 1 ha una dimensione di 250.000 byte [250kB] e il file 2 di 25.000.000 byte [25MB]. [...]
Come si può vedere dalla Fig.1, la dimensione del file non ha molta influenza sulla garbage collection finché il file non è molto grande. Tutti e cinque i drive hanno registrato eventi di garbage collection normalmente in un periodo di tempo compreso tra 5 e 15 secondi.

Qui il testo non tradotto con Figura 1 (P.S.: nella Figura 1 non c'è il BX500 perché era il sample a cui non funzionava il garbage collection).

Un BX500 ha fallito nel far funzionare il garbage collection per, a detta degli autori, di alcuni glitch hardware o software. Alcuni BX500 e 870 EVO, invece, mantenevano dei piccoli frammenti nonostante il garbage collection ma non si poteva comunque recuperare gli interi file. Altri risultati interessanti sono stati che per alcuni esemplari sia di BX500 che di 870 EVO non c'è stato alcun evento di TRIM e di garbage collection e questi file fossero facilmente recuperabili.

Conclusione? TRIM e garbage collection sono direi lontani dall'essere perfetti e possono anche funzionare male/non funzionare per file così piccoli. Sarei curioso di vedere gli stessi esperimenti ma con file di dimensioni più grandi come nell'ordine di decine e centinaia di GB.

[frafelix]

Interessante! In effetti per il trim ti affidi a due parti, il sistema operativo che manda il comando e l'ssd che lo esegue, quindi puoi avere due eventi che non funzionano o funzionano in modo anomalo.
Per il gc entra in gioco solo l'ssd, ma non essendoci uno standard e non avendo controllo su di esso, ti devi fidare che funzioni nel modo corretto.

Riguardo al recupero di file di decine o centinaia di gb, mi verrebbe da dire a logica, che più il file è grande più difficile sarà recuperarlo dato che, anche ipotizzando un malfunzionamento sia di trim che di gc, basta che il gc cancelli qualche byte del file (che per lui non è un indirizzo di memoria unico per tutto il file) ed ecco che non sarà recuperabile, oppure lo sarà con qualche errore

[@Liupen]

Originariamente inviato da Black (Wooden Law)

L'unica cosa che c'entra con le NAND flash di "metallo per il livello di interconnessione" sono i contatti che si usano per collegare le bitline alle celle NAND flash. Guarda questa foto e guarda "Contact: Tungsten metal fill".

Dal momento che questi contatti fungono da interconnessioni nell'array NAND flash (e penso che si stendino pure allo strato CMOS), non è che stanno dicendo "a seguito di una riduzione dimensionale e quantitativa dei PB, abbiamo dovuto raddoppiare le interconnessioni di metallo ottimizzando la parte CMOS"? ha senso secondo te?

Si. Approfondendo è proprio come hai detto.

è stato introdotto un processo di raddoppio del passo del metallo per il livello di interconnessione, nonché un'attenta ottimizzazione del dispositivo CMOS

Diciamo che è la figura 8 che andrebbe interpretata...




Andava oltre le mie conoscenze sui tipi di staircase delle word‑line, questo spiega il mio "non capire".



In questi giorni, anche se non ho potuto scrivere, ho approfondito anch'io l'argomento (testardaggine nel capire)


--------------------


Partiamo dalla famosa scala doppia della struttura del die array (è un ragionare con te il mio) e mi stò facendo dare pure delle definizioni da Chatgpt per avere le idee un po più chiare.

https://i.ibb.co/QvrzFS7M/saFGTWR.png

i "gradini" servono a esporre layer per layer le wordline.
quindi da questi punti di connessione partono i driver, ovvero i filamenti che portano le tensioni (o le trasmettono ad un gestore che magari è esterno ma alla fine per forza arriva in una parte del CMOS).

Per un incremento più rapido del potenziale di word-line durante l'operazione di lettura, la riduzione di metà del WL-RC è stata comunemente applicata nei prodotti più recenti, ma nella maggior parte dei casi è accompagnata dalla duplicazione di un set di driver di stringa per pilotare ogni metà del WL in un piano.

Come anche già detto prima, dice che comunemente già gli altri utilizzano
1 - la riduzione di metà del WL-RC
2 - accompagnata dalla duplicazione di un set di driver di stringa per pilotare ogni metà del WL in un piano

(ahaha! adesso devo tradurre e rendere semplice da capire cosa mi scrive l'Ai in proposito....)

1 -

WL-RC è la resistenza che incontra il segnale di lettura. Più alto è il WL‑RC, più lenta sarà la variazione di tensione (ritardo maggiore), e di conseguenza aumenterà il tempo di accesso (read/write).

Semplificando:

WL-RC alto = lettura lenta
WL-RC basso = lettura veloce

Si parla di ridurre della metà la resistenza alla lettura, quindi di rendere più veloce (il doppio più veloce?) la lettura dei dati.

L'AI suggerisce che: a parità di driver, dimezzare R·C può essere ottenuto riducendo la resistenza del percorso (montando driver più forti o più vicini) oppure abbattendo la capacità di carico (suddividendo lo stack in sub‑blocchi più piccoli, o riducendo il pitch dei metalli).
Ne discende che una duplicazione dei driver ottiene l'effetto di ridurre WL-RC.
Inoltre, sempre l'AI, dice: caricare e scaricare una capacità minore o attraverso una resistenza minore richiede meno energia complessiva.


2 -

la duplicazione del driver, cioè del collegamento delle WL è conseguente alla duplicazione delle WL per piano (perchè appunto G9 adotta la doppia scala)
https://i.ibb.co/QvrzFS7M/saFGTWR.png


Mettendo insieme 1 e 2 ed il testo:
Per un incremento più rapido del potenziale di word-line durante l'operazione di lettura, COME FANNO TUTTI, abbiamo utilizzato una struttura a scala doppia che ha permesso di raddoppiare WL e di conseguenza duplicare le linee di comunicazione (driver) delle WL, accompagnate, COME EFFETTO PREVISTO, da una riduzione della WL-RC e dunque un aumento della velocità di lettura.


Poi il testo continua:
Come mitigazione, è stata applicata una maggiore condivisione dei driver aumentando il numero di sottoblocchi per blocco per ridurre il numero totale di driver per piano, ma con un aumento del caricamento dell'array e della corrente di funzionamento. La scala bidirezionale (SC) ha risolto il compromesso tra latenza di lettura, energia di lettura per bit ed efficienza dell'array, mostrato in Figura 8.


La "mitigazione", ecco, come ho scritto in precedenza non ha molto senso dover mitigare qualcosa che sembra solo positivo.

Ma è la frase in se ad essere poco chiara. Infatti sarebbe giusto dire che si parla di indicatori di costo‑prestazione legati alla gestione delle word‑line (WL) quindi alla capacità di lettura delle die. In questo frangente abbiamo 3 elementi (vedi figura 8): la resistenza del segnale WL-RC, l'area del CMOS (contenenti anche i driver) ed infine la capacità intrinseca del metallo/polisilicio della WL stessa (capacità di carico?).

Nella situazione diciamo...base, questi tre elementi sono:

WL-RC media
WL Driver Area alta
WL Loading Capacity normale o fissa (dipende dalle caratteristiche del semiconduttore)

Cosa vuole ottenere Micron nelle G9?
Risposta: che WL-RC sia più bassa possibile

Cosa avviene di... come dire... imprevisto?
Che le die tra G8 e G9 si riducono di area [die size reduction from 1Tb G8 to G9 of 30%] quindi WL Drive Area si riduce (il CMOS che stà sopra o sotto a seconda della struttura al die, deve essere piccola quanto il die).
La riduzione dell'area di CMOS crea però un aumento di WL-RC!

...ed ecco finalmente il senso di "mitigazione"


La miniaturizzazione del CMOS nel suo effetto non positivo (diciamo così) sulle prestazioni di lettura deve essere contrastato da delle azioni (strutturali) che permettano di mantenere la lettura decente.


Ho quindi chiesto all'AI il senso della mitigazione, e la risposta è stata: In questo contesto il termine “mitigazione” indica la strategia usata per attutire (ovvero compensare) il principale svantaggio della riduzione di WL‑RC, “dimezzando” la word‑line, cioè la duplicazione del set di driver sotto ogni metà di WL.

L'AI continua dicendo che:
– Se dimezzi WL‑RC spezzando la word‑line in due metà, per mantenere la stessa capacità di gestione devi mettere due driver al posto di uno, raddoppiando così l’area CMOS sotto array.
– Per mitigare questo raddoppio di driver (e quindi l’aumento di area e costo), i progettisti hanno invece scelto di aumentare il numero di sottoblocchi (sub‑block) per ogni blocco.
– In questo modo un singolo driver (o un gruppo di driver) può essere condiviso tra più metà‑WL di sub‑blocchi diversi, riducendo il conteggio complessivo dei driver richiesti per piano.

è l'interpretazione della famosa Figura 8 che accompagna la spiegazione sopra, per ottenere:

WL-RC bassa
WL Driver Area piccola
WL Loading Capacity normale o fissa (dipende dalle caratteristiche del semiconduttore)


ottenuta attraverso una diversa architettura di blocco 3D‑NAND in termini di “staircase” delle word‑line (WL).


Quindi per capire ora fino in fondo, bisogna capire questa nuovo struttura com'è.

Per me per esempio è difficile vedere lo schema di figura 8 in maniera tridimensionale.

Quindi ho cercato una rappresentazione quanto più simile al reale 3D di questa struttura Micron https://patents.google.com/patent/US9721668B2/en

Ricordo che, la struttura, per contrastare la miniaturizzazione del CMOS e l'aumento della velocità di lettura, è stata pensata (originale o copiata non so):

- "aumentando il numero di sottoblocchi per blocco per ridurre il numero totale di driver per piano" --> che però ha come effetto "un aumento del caricamento dell'array e della corrente di funzionamento".

a cui si rimedia a sua volta:

- "La scala bidirezionale (SC) ha risolto il compromesso tra latenza di lettura, energia di lettura per bit ed efficienza dell'array".


Della scala bidirezionale, diciamo che sappiamo come è fatta
https://i.ibb.co/QvrzFS7M/saFGTWR.png

e si può presumere che aiuti a mantenere WL-RC bassa ed ad usare meno energia per la lettura. Quindi dà efficienza nel complesso.


Della struttura del die bisogna invece capire com'è.

Ecco il mio errore... non riguarda la struttura dei die come la scala (SC), ma come vengono organizzati i blocchi. Che pirla che sono Black!
La die rimane quella struttura ma sono aggiunte delle strip di connessione e organizzate diversamente.

La config. generale è: array di un gruppo di celle 3D --> array di Pagine --> Blocco

Per l'architettura NAND Flash convenzionale, il "blocco" è definito da un raggruppamento fisico che include le stringhe NAND configurate tra un insieme di bitline (BL) e una linea sorgente comune (CSL) con un insieme di wordline intersecanti (WL)




Split delle WL: anziché pilotare un’unica lunga WL, le si suddivide in 2 (o più) sottoblocchi.

Condivisione driver: uno stesso driver (o set di driver) viene collegato via RSL alle WL di più sottoblocchi in sequenza, riducendo il count di driver fisici.

Come effetti indesiderati, abbiamo ovviamente che essendo un driver collegato a più WL è più soggetto a lavoro e serve più corrente per caricare queste WL multiple con un unico driver.

Invertendo queste osservazioni si ottiene cosa dice il testo: "una maggiore condivisione dei driver aumentando il numero di sottoblocchi per blocco per ridurre il numero totale di driver per piano, ma con un aumento del caricamento dell'array e della corrente di funzionamento".

[Black (Wooden Law)]

Originariamente inviato da @Liupen

(o le trasmettono ad un gestore che magari è esterno ma alla fine per forza arriva in una parte del CMOS).

Giusto, parli delle pompe di carica. Guarda qui e qui, fanno parte del CMOS ed è un circuito elettronico che fornisce la tensione al dispositivo (in questo case le celle NAND flash). Samsung aveva parlato di questo circuito nella presentazione delle V6 (128L TLC) all'ISSCC per dire che COP ostacola la creazione di grandi condensatori all'interno delle pompe di carica impedendo di costruire degli alti contatti di metallo (qui la presentazione, vedi slide 7).

Originariamente inviato da @Liupen

Invertendo queste osservazioni si ottiene cosa dice il testo: "una maggiore condivisione dei driver aumentando il numero di sottoblocchi per blocco per ridurre il numero totale di driver per piano, ma con un aumento del caricamento dell'array e della corrente di funzionamento".

Bravi gli ingegneri (di non so quale azienda visto che una scopiazza l'altra ) che hanno trovato questi escamotage per impilare sempre più layer in ogni NAND flash.

Alla fine il processo è: per ridurre il ritardo RC delle WL tagliamole in due -> per collegare le WL tra di loro usiamo delle scale condivise -> abbiamo raddoppiato il numero di driver delle stringhe e quindi anche la dimensione dello strato CMOS, questo è un male. Per risolvere creiamo più sottoblocchi in modo tale da far condividere meno driver delle stringhe possibili con più WL di sottoblocchi diversi.

[@Liupen]

Originariamente inviato da Black (Wooden Law)

Questo lo trovo interessante riguardo alla discussione che abbiamo avuto io, @Liupen, Sbaffo e Frafelix sull'SSD nel PC Mac di Frafelix: Solid-State Drive Over-Provisioning Technology and its Impact on the Ability to Erase Individual Files.


Qui sembra parlare indirettamente di un secure erase con dati randomici, cioè tutti 1:


Qui le due parti non tradotte. [4] è Reliably Erasing Data From Flash-Based Solid State Drives, [5] è ErasuCrypto: A Lightweight Secure Data Deletion Scheme for Solid State Drives, [7] è Deleted Data Recovery on Solid-State Drives by Software Based Methods.

Le conclusioni dello studio sono che divide in tre gruppi i metodi per la cancellazione dei file negli SSD:
1. metodi che richiedono la modifica del firmware e che non sono utilizzabili nella pratica perché SSD di diversi produttori con diversi chip NAND flash e diversi "algoritmi di funzionamento del controller interno" sono installati su computer protetti;
2. metodi tramite dei software che spesso non spesso non sono sufficientemente affidabili anche per la parte del recupero;
3. tecnologie di cancellazione dei dati tramite crittografia che cancellano l'intero SSD e non i singoli file e richiedono modifiche al firmware.

In quanto all'OP, dice che rende inefficace il "mashing" dei dati nello spazio libero dell'SSD, che parte dello spazio degli indirizzi non è accessibile ai software e che non è possibile cancellare i dati senza interferire con il firmware dell'SSD o usando i software dei produttori di SSD. In questo caso le cancellazioni tramite crittografia sono utili.
-------------------------------------------------------
Anche lo studio [7], Deleted Data Recovery on Solid-State Drives by Software Based Methods è rilevante alla discussione.

Hanno testato (su Windows 10 Enterprise 21H1) 2 870 EVO, 8 860 EVO e 8 BX500 e altri SSD di cui ci interessa relativamente con 3 testi di file da rispettivamente 250B, 250kB e 25MB. I risultati sono che i file da 250B non sono stati eliminati dal garbage collection perché Master File Table (MFT) di NTFS contiene i file da meno di 700B e l'eliminazione di file piccoli non porta a far azionare il TRIM perché le modifiche vengono effettuate nella MFT. Per quanto concerne i file da 250kB e 25MB, tutti i garbage collection degli SSD ci hanno messo dai 5 ai 15 secondi per fare il loro (tranne per l'Intel 760p da 256GB dove ci ha messo dai 6,2 secondi ai 4,22 minuti).


Qui il testo non tradotto con Figura 1 (P.S.: nella Figura 1 non c'è il BX500 perché era il sample a cui non funzionava il garbage collection).

Un BX500 ha fallito nel far funzionare il garbage collection per, a detta degli autori, di alcuni glitch hardware o software. Alcuni BX500 e 870 EVO, invece, mantenevano dei piccoli frammenti nonostante il garbage collection ma non si poteva comunque recuperare gli interi file. Altri risultati interessanti sono stati che per alcuni esemplari sia di BX500 che di 870 EVO non c'è stato alcun evento di TRIM e di garbage collection e questi file fossero facilmente recuperabili.

Conclusione? TRIM e garbage collection sono direi lontani dall'essere perfetti e possono anche funzionare male/non funzionare per file così piccoli. Sarei curioso di vedere gli stessi esperimenti ma con file di dimensioni più grandi come nell'ordine di decine e centinaia di GB.

Solid-State Drive Over-Provisioning Technology and its Impact on the Ability to Erase Individual Files

Quello che mi salta subito all'occhio è esordire/affermare che esistono: "metodi noti che, a loro avviso, garantiscono la cancellazione sicura dei singoli file eliminati dai supporti SSD.". Visto che conoscendo come è fatto e come funziona un ssd, pare impossibile, mette curiosità continuare a leggere.

Eccoli
1
"è stato proposto di modificare il livello di astrazione di un'unità a stato solido (FTL) al fine di eseguire una procedura di garbage collection forzata"
2
mashing con scansione. Nella pratica, il controller dell'unità a stato solido esegue la scansione delle aree libere dell'unità e, se rileva blocchi occupati da dati, li cancella
3
cancellazione delle informazioni a livello di blocco dati delle unità SSD (modificando da zero a uno ciascuno dei bit di questo blocco, utilizzato per memorizzare i dati non cancellati



Sono algoritmi da introdurre, non metodi attuabili con gli strumenti di adesso, ecco il perchè.

"In tutti i casi, le prestazioni e la durata del dispositivo sono diminuite."
Eh...infatti, tutto sto GC in più quell'effetto fà...

Ma io dico: che importanza può avere cancellare un singolo file in maniera sicura quando basta usare la criptazione e si risolve il problema all'origine?
Ops... lo scrivono anche loro... e per giustificare lo studio scrivono che la criptazione: "richiedono un notevole impiego di risorse di elaborazione, il che porta a una significativa riduzione della velocità di scrittura/lettura dei dati da un'unità SSD"

Io non sarò un esperto ma so che la criptazione richiede solo una P2P con chiave nascosta... nessun passaggio in più di quello che fà già il controller.
Vari studi hanno dimostrato che criptare non toglie risorse di calcolo o cali di velocità.

Questo non mi è nuovo: "Inoltre, in [4] è stato dimostrato che, anche con un comando TRIM eseguito correttamente, i dati cancellati possono rimanere sull'unità per un periodo di tempo piuttosto lungo prima che il garbage collector li acceda."



Ad un certo punto, degli ssd con TRIM attivo scrivono: "In questo caso, la probabilità di ripristinare i metadati del file è molto elevata."
cosa con cui non mi trovo d'accordo. Dipende da quanto e se è implementata l'azzeramento dei vaolori di mappatura. In un contesto di ssd PRO sono ormai standard credo. Certo se il riferimento preso è un ssd Samsund 870 evo...


Deleted Data Recovery on Solid-State Drives by Software Based Methods

Non l'ho ancora letto, ma dal sunto che fai, in linea con quanto avevo scritto https://www.hwupgrade.it/forum/showp...ostcount=23226



----

Originariamente inviato da Black (Wooden Law)

Alla fine il processo è: per ridurre il ritardo RC delle WL tagliamole in due -> per collegare le WL tra di loro usiamo delle scale condivise -> abbiamo raddoppiato il numero di driver delle stringhe e quindi anche la dimensione dello strato CMOS, questo è un male. Per risolvere creiamo più sottoblocchi in modo tale da far condividere meno driver delle stringhe possibili con più WL di sottoblocchi diversi.

Esattamente!

Anzi

Alla fine il processo è: per ridurre il ritardo RC delle WL tagliamole in due -> per collegare le WL tra di loro usiamo delle scale condivise -> abbiamo raddoppiato il numero di driver delle stringhe e quindi anche la dimensione dello strato CMOS, e l'energia che ci vuole per leggere, questo è un male. Per risolvere creiamo più sottoblocchi in modo tale da far condividere meno driver delle stringhe possibili con più WL di sottoblocchi diversi, riducendo il carico di tensione perchè condiviso.

[frafelix]

Se non mi ricordo male, se l'ssd non supporta la criptazione in hardware, si deve appoggiare alla cpu e sicuramente hai dei rallentamenti; magari non percepibili con le ultime cpu, ma sicuramente è un passaggio in più.
Poi magari si perde qualche mb/s e chi se ne accorge, ma sicuramente anche la criptazione hardware porta a dell'overhead in più.
Come quando si mettono i dischi in raid, a parte l'affidabilità, se hai un controller separato è meglio che farlo gestire al chipset della scheda madre e di conseguenza il chipset è meglio che far gestire il raid a windows...

Riguardo alla criptazione per sopperire alle mancanze di trim e gc ed avere la garanzia che non si possono recuperare i dati, ti riporto una mia esperienza: Mac utilizzato per lavoro, senza criptazione dei dati ed esigenza di cancellare lo spazio libero in modo sicuro.
Cosa fai?
Non puoi fare il secure erase perché il Mac deve rimanere operativo, non puoi attivare la criptazione e disabilitarla perché i dati cancellati prima non vengono processati dalla criptazione e quindi sono recuperabili se il gc non è intervenuto. L'unico modo è fare un secure erase dello spazio vuoto, ma non mi pare ci siano programmi che lo facciano, ci sono programmi invece che sovrascrivono lo spazio vuoto (cosa più adatta agli hd meccanici).

In ogni caso stiamo parlando di macchine in cui abbiamo la totale autonomia. Se invece parlassimo di pc aziendali dove per policy non puoi attivare la criptazione? Come hanno standardizzato il trim, dovrebbero farlo anche con il gc e far si che ci sia un addetto alla verifica.
Un po' come gli standard iso che per essere compliant un addetto viene a fare delle verifiche, oltre alle scartoffie. Nelle memorie c'è la jedec, e via discorrendo

[Black (Wooden Law)]

Originariamente inviato da @Liupen

Io non sarò un esperto ma so che la criptazione richiede solo una P2P con chiave nascosta... nessun passaggio in più di quello che fà già il controller.
Vari studi hanno dimostrato che criptare non toglie risorse di calcolo o cali di velocità.

Secondo me con quell’affermazione si riferiscono allo studio [5], cioè ErasuCrypto. Lì se vai a leggere nello studio dicono che la cancellatura con crittografia tocca le performance dell’SSD perché se c’è da dover cancellare una pagina e basta si va a usare grandi volumi di chiavi (e una chiave corrisponde ad una pagina se non erro).

Comunque lo studio di ErasuCrypto è del 2016, può essere che la tecnologia sia cambiata un po’ da 9 anni. Ammetto di non aver mai studiato la cancellazione tramite crittografia nelle NAND flash/SSD, sarebbe forse il momento di farlo…

Originariamente inviato da @Liupen

Questo non mi è nuovo: "Inoltre, in [4] è stato dimostrato che, anche con un comando TRIM eseguito correttamente, i dati cancellati possono rimanere sull'unità per un periodo di tempo piuttosto lungo prima che il garbage collector li acceda."



Ad un certo punto, degli ssd con TRIM attivo scrivono: "In questo caso, la probabilità di ripristinare i metadati del file è molto elevata."
cosa con cui non mi trovo d'accordo. Dipende da quanto e se è implementata l'azzeramento dei vaolori di mappatura. In un contesto di ssd PRO sono ormai standard credo. Certo se il riferimento preso è un ssd Samsund 870 evo...

Mi sembrano abbastanza correlate le due parti: può esserci anche il TRIM attivo ma se il garbage collector non fa il suo i dati possono essere recuperabili senza problemi, indipendentemente se la mappa L2P sia stata aggiornata o meno.

[@Liupen]

Originariamente inviato da Black (Wooden Law)

Secondo me con quell’affermazione si riferiscono allo studio [5], cioè ErasuCrypto. Lì se vai a leggere nello studio dicono che la cancellatura con crittografia tocca le performance dell’SSD perché se c’è da dover cancellare una pagina e basta si va a usare grandi volumi di chiavi (e una chiave corrisponde ad una pagina se non erro).

Comunque lo studio di ErasuCrypto è del 2016, può essere che la tecnologia sia cambiata un po’ da 9 anni. Ammetto di non aver mai studiato la cancellazione tramite crittografia nelle NAND flash/SSD, sarebbe forse il momento di farlo…

Originariamente inviato da frafelix

Se non mi ricordo male, se l'ssd non supporta la criptazione in hardware, si deve appoggiare alla cpu e sicuramente hai dei rallentamenti; magari non percepibili con le ultime cpu, ma sicuramente è un passaggio in più.
Poi magari si perde qualche mb/s e chi se ne accorge, ma sicuramente anche la criptazione hardware porta a dell'overhead in più.
Come quando si mettono i dischi in raid, a parte l'affidabilità, se hai un controller separato è meglio che farlo gestire al chipset della scheda madre e di conseguenza il chipset è meglio che far gestire il raid a windows...

Vero Black, ho citato quella frase riferita al metodo che citi, ma anche dopo nel testo si ripete questo concetto in rappresentanza di tutta la criptazione.
Da cosa capisco, la criptazione (software) può essere usata per cancellare i file interessati, perchè agisce applicando un filtro ad ogni file criptato, e quindi si userebbe questo "marker" per rintracciare la posizione fisica del dato stesso.

Come da te puntualizzato, frafelix, la criptazione software (che poi chiaramente è quella di Bitlocker), toglie delle risorse di calcolo (a mio parere trascurabili o nulle se acquisto appunto un ssd che utilizza una criptazione hardware + bitlocker).
Ti quoto nel dire, se uno a da fare un RAID o un sistema criptato, che si scelga ssd che supporti protocollo TCG/Opal tipo hardware.

Come detto non sono un esperto, e come scrivi, se l'impatto c'è, sono il primo a dire - per come so che funziona Bitlocker - "non percepibili con le ultime cpu".
Microsoft non ha mai evidenziato problemi di velocità ed articoli come questo https://www.tomshardware.com/news/wi...mments-3823680
-45% rilevato da THW mi fà sospettare che non dipenda interamente dalla criptazione (ed il bello che i dubbi li hanno anche loro ma non approfondiscono... in perfetto stile "articolo clickbait")

Originariamente inviato da Black (Wooden Law)

Mi sembrano abbastanza correlate le due parti: può esserci anche il TRIM attivo ma se il garbage collector non fa il suo i dati possono essere recuperabili senza problemi, indipendentemente se la mappa L2P sia stata aggiornata o meno.

L'evidenza del reale (l'empirico) però ci dice che, con il TRIM attivo, la "finestra" tra comando TRIM e seguente GC non è scontata, anzi.
Molti DR arrivano ad affermare che è più facile cavar fuori dati da un ssd rotto piuttosto che recuperare un dato cancellato da un ssd.
Comunque il discorso principale è che con gli ssd attuali e per rispondere alle normative cocenti, ci si sposta verso SSD che implementano almeno uno dei due meccanismi DRAT (Deterministic Read After Trim) o DZAT (Deterministic Zeroes After Trim), per cui dopo un comando TRIM il drive restituirà sempre lo stesso valore (tipicamente tutti zeri) e non i dati originali.
https://blog.elcomsoft.com/2025/06/w...-ssd-forensics

Originariamente inviato da frafelix

Riguardo alla criptazione per sopperire alle mancanze di trim e gc ed avere la garanzia che non si possono recuperare i dati, ti riporto una mia esperienza: Mac utilizzato per lavoro, senza criptazione dei dati ed esigenza di cancellare lo spazio libero in modo sicuro.
Cosa fai?
Non puoi fare il secure erase perché il Mac deve rimanere operativo, non puoi attivare la criptazione e disabilitarla perché i dati cancellati prima non vengono processati dalla criptazione e quindi sono recuperabili se il gc non è intervenuto. L'unico modo è fare un secure erase dello spazio vuoto, ma non mi pare ci siano programmi che lo facciano, ci sono programmi invece che sovrascrivono lo spazio vuoto (cosa più adatta agli hd meccanici).

In ogni caso stiamo parlando di macchine in cui abbiamo la totale autonomia. Se invece parlassimo di pc aziendali dove per policy non puoi attivare la criptazione? Come hanno standardizzato il trim, dovrebbero farlo anche con il gc e far si che ci sia un addetto alla verifica.
Un po' come gli standard iso che per essere compliant un addetto viene a fare delle verifiche, oltre alle scartoffie. Nelle memorie c'è la jedec, e via discorrendo

Ti posso dire cosa avrei fatto io: tolto i dati temporaneamente, creato una nuova partizione, attivare su quella la criptografia (software) e infine ricopiarci i dati (ora criptati). Alla fine hai l'OS in chiaro e i dati criptati.

[frafelix]

Originariamente inviato da @Liupen

Ti posso dire cosa avrei fatto io: tolto i dati temporaneamente, creato una nuova partizione, attivare su quella la criptografia (software) e infine ricopiarci i dati (ora criptati). Alla fine hai l'OS in chiaro e i dati criptati.

In questo caso però non cripti i dati già cancellati (credo). Lo spazio contrassegnato come vuoto come viene gestito? Perché tu cripti i file mica fisicamente le celle, quindi i dati già cancellati dovrebbero essere comunque recuperabili…

[Black (Wooden Law)]

Originariamente inviato da @Liupen

L'evidenza del reale (l'empirico) però ci dice che, con il TRIM attivo, la "finestra" tra comando TRIM e seguente GC non è scontata, anzi.
Molti DR arrivano ad affermare che è più facile cavar fuori dati da un ssd rotto piuttosto che recuperare un dato cancellato da un ssd.
Comunque il discorso principale è che con gli ssd attuali e per rispondere alle normative cocenti, ci si sposta verso SSD che implementano almeno uno dei due meccanismi DRAT (Deterministic Read After Trim) o DZAT (Deterministic Zeroes After Trim), per cui dopo un comando TRIM il drive restituirà sempre lo stesso valore (tipicamente tutti zeri) e non i dati originali.
https://blog.elcomsoft.com/2025/06/w...-ssd-forensics

Sì infatti trovo gli esperimenti di quello studio interessanti ma nulla di più, non li prendo come oro colato. Hanno usato SSD SATA III e non NVMe più recenti e in più hanno usato soltanto file di piccole dimensioni quando secondo me sarebbe stato più utile testare con decine e centinaia di GB.

Utile per sapere che file da meno di 700B non risentono del GC e del TRIM, utile sapere che c’è una possibilità di recuperare i dati in caso il GC non agisse subito, ma il concetto che sugli SSD il recupero dei dati è ostico e che molto probabilmente la cancellazione di un file compromette a non recuperarlo più rimane.

[@Liupen]

Originariamente inviato da frafelix

In questo caso però non cripti i dati già cancellati (credo). Lo spazio contrassegnato come vuoto come viene gestito? Perché tu cripti i file mica fisicamente le celle, quindi i dati già cancellati dovrebbero essere comunque recuperabili…

Non cripti i non-dati o lo spazio vuoto (criptazione software).

Con la copia metti in moto un GC che sovrascrive; poi di pende dall'ssd, magari è tra quelli che hanno DZAT come gestione.
Per recuperare inoltre quei dati serve un data recovery specializzato.
Qualche bastone tra le ruote c'è, insomma..