PDA

View Full Version : SSD: thread generale e consigli per gli acquisti


Pagine : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 [93] 94 95 96

megthebest
14-04-2025, 16:26
grazie

il vecchio finisce in pattumiera
no dai... magari ci sono milioni di euro in btc:D

Antonio Latrippa
14-04-2025, 16:41
no dai... magari ci sono milioni di euro in btc:D

tenderei a escluderlo, altrimenti non girerei con un pc vecchio di 12 anni :D

sbaffo
14-04-2025, 17:19
E non lasciare il vecchio HD connesso contemporaneamente all'SSD clonato quando riavvierai per la prima volta il PC dopo l'operazione, o avrai serii problemi a ripristinare il corretto funzionamento del bootloader di Windows. Perchè?
E solo la prima volta? dopo no?

s12a
14-04-2025, 17:57
Perchè?
E solo la prima volta? dopo no?

Perché quando viene clonato il sistema, il boot loader (BCD / Boot Configuration Data) della partizione clonata rimane in uno stato "indeterminato" e se avvii il sistema con il vecchio dispositivo di memorizzazione connesso, andrà a fare riferimento in maniera permanente alla vecchia installazione, e la procedura per ripristinare la situazione è una seria rottura di scatole. Se questo accade e rimuovi il vecchio HD, il sistema non si avvierà, darà un errore di "dati mancanti" o qualcosa del genere.

https://i.imgur.com/N3XKDtf.png

Se invece non connetti subito il vecchio HD, il BCD si auto-configurerà (si spera) in maniera corretta per la nuova configurazione, dopodiché sarà possibile connettere il vecchio HD ed avviare entrambi i sistemi in maniera indipendente selezionando il disco di avvio (tipicamente con il tasto F11 nella fase di boot).

Il problema è discusso in rete da varie fonti.

- https://blog.xavier2dc.fr/2022/04/12/cloned-ssd-wont-boot-the-correct-way-to-fix-it/
- https://www.tenforums.com/general-support/207947-cloned-ssd-cant-boot-broken-bcd.html
- ecc.

frafelix
14-04-2025, 17:58
Per non far casino devi togliere la partizione di avvio dal vecchio hd, altrimenti ci saranno due boot loader attivi... Di norma dovrebbe partire prima quello nella porta sata con numero più basso, ma non sempre accade

@Liupen
14-04-2025, 18:55
Sei sicuro Liupen? Qui (https://imgur.com/a/EAkwhvE) i Cortex-R8 sono il 26% in meno efficienti degli R5.

L'immagine fà un confronto di prestazioni, a parità di condizioni, R8 elabora più dati per ciclo: frequenza massima e quindi aumento delle prestazioni (33%).
Morfologicamente è di quasi il 60% più grande ed è, come fai notare, anche più energivoro (+26%) a parità di operazioni elaborate.
Si tratta però di efficienza per operazione, tu invece considera che la velocità operativa dell'R8 è migliore e quindi che le operazioni saranno più brevi con risparmio di tempo/energia.
A rafforzare questo dato è il sistema di implementazione fornito al Cortex R8, che nei white paper trovi sotto la voce scalabilità.
I core possono anche essere eseguiti in modo asimmetrico e ciascuno ha un proprio piano di alimentazione, il che significa che possono essere disattivati ​​per risparmiare energia.
L'area del processore, la frequenza e il consumo energetico dipendono fortemente dal processo, dalle librerie e dalle ottimizzazioni.
Questa flessibilità permette di distribuire il carico su più core, riducendo ulteriormente il tempo totale di elaborazione per carichi parallelizzabili e, di conseguenza, migliorando l’efficienza energetica complessiva.


@Liupen

solitamente svolgo solo una scrittura di 1 con DiskGenius, da HBCD
più che sufficiente
conosci software free validi per (tentativo) recupero dati da ssd dopo erase, quindi senza fs?

Come detto sopra non ci sono software, con licenza o meno, che possano recuperare dati, specie se hai fatto 1 passaggio di scrittura completa.
Il fatto è che succede anche se si fà una formattazione semplice, a patto che ci sia il TRIM attivo sul sistema operativo con cui formatti.
Il messaggio di TRIM viene messo in coda dopo una scrittura pesante e svolto dal controller anche se lo stacchi... appena gli dai energia lo esegue e azzera la mappatura, quindi non fà trovare niente di coerente visto che un ssd scrive in ordine sparso e non sequenzialmente come negli hdd.
Per questo meccanismo del TRIM che entra in funzione, viene consigliato ai Clienti dai servizi di Data Recovery che se vogliono recuperare i dati da un ssd (che ha perso l'mbr o sono stati cancellati dati erroneamente) di spegnerlo immediatamente e gli stessi DR quando hanno in mano l'ssd, isolano il controller bloccando il TRIM, e poi simulando via software (con uno strumento apposito) la presenza di un controller identico, da cui leggere i dati.

Provo a dare un'occhiata a Parted Magic come consigliato anche da The_Saint nella pagina prima.

Comunque il secure erase non ha anche il vantaggio che ripristinando le celle come da nuovo elimina anche possibili casini (bug) del firmware nel caso di dati vecchi (tipo i vecchi Samsung 840 lisci)? Mi pareva di ricordare che all'epoca per ripristinare le performance prima che correggessero il bug, si dovesse fare il secure erase e che la semplice riscrittura di 0 fill non andasse bene. Lo step successivo, sempre prima dell'aggiornamento firmware, fu la nascita di programmi che facevano il refresh dei dati (che riscrivevano l'intero contenuto dell'ssd)

Non casini del firmware, il discorso è un altro, ma molto semplice.

Quando hai un ssd nuovo, hai tutte le celle su 1 (binario) cioè quello che consideriamo valore nullo/cella vuota.
Nel primo giro di scrittura (pari alla dimensione in GB dell'ssd), le celle - come fosse un hdd con le testine nel solco - vengono scritte una a una sequenzialmente, dalla prima all'ultima (perchè ci sono sempre più celle libere davanti che dietro dove eventualmente si creano dei "buchi" per via di qualche nostra cancellazione.

Quando parte il secondo ciclo (in crystaldiskinfo vediamo comparire 99%), vuol dire che quelle scritture su ssd dovranno essere sempre precedute dalla loro cancellazione. Devono tornare al valore binario 1 per essere riscritte... le nand flash funzionano così.
La cancellazione prima della scrittura porta via tempo, quindi aumenta la latenza di scrittura se i dati sono fitti e sequenzialmente importanti. Un po è compensato dalla velocità della cache di scrittura SLC ma non totalmente.

Quindi c'è (una volta con algoritmi meno efficienti ai tempi dei Samsung 840, molta di più) differenza dal punto di vista delle prestazioni se l'ssd viene cancellato con un secure erase (di nuovo tutte le celle vuote), oppure con una formattazione rapida/avanzata o anche zero-fill (perchè in questo caso il controller vede celle scritte da cancellare anche se l'ssd pare vuoto).

L'introduzione del refresh dei dati nasce come dici con il famoso bug del modello Samsung.
In teoria è un algoritmo di tutti i firmware degli ssd. In teoria perchè realmente non è più necessario usarlo; aumenta a dismisura la Write Amplification e non porta miglioramenti.
Diciamo che oggi (dagli ssd di terza generazione in poi 2015-2016) anche se molti dati rimangono effettivamente statici, l'uso della parte rimanente delle celle è longeva quanto basta...anzi e inoltre i dati permangono molto più di quanto si pensi perchè nel frattempo sono migliorati gli algoritmi ECC di recupero/interpretazione del dato letto ed eventualmente riscritto altrove.


oddio, per il bug del 840 il secure erase non me lo ricordo, ma la riscrittura dei dati sì :)

riscrittura che, approfitto, IMHO andrebbe fatta ancora oggi manualmente almeno una volta l'anno per tutti i dischi ssd (sata o nvme che siano) secondari. Non per bug prestazionali ma perché se non sbaglio a tutt’oggi il massimo di GC-WL su di essi che si può avere è la funzionalità programmabile “ottimizza” di windows (una trimmata) ;)



Ma come non ti ricordi?
Non avevi il Samsung se no saresti stato li a scaricare e fare questo software per vedere l'età dei dati statici in relazione alla velocità di lettura :read: https://www.majorgeeks.com/files/details/ssd_read_speed_tester.html


Windows la situazione da qualche versione in qua è questa:
Ottimizza è un comando TRIM
La funzione programmabile sotto è - anche per gli ssd - un vero e proprio defrag.

Come mi sembra anche detto più volte da s12a, la deframmentazione negli ssd è periodicamente necessaria per mantenere i tempi di ricerca dei dati nei parametri; troppa deframmentazione (senza arrivare ai limiti dell'ingestibilità) fà lavorare di più il controller.
Dite le riscritture?
Balle! E' stata una delle cose che ho testato su un ssd, perchè richiede veramente poco: scritto un ssd sata da 500GB per il 30% dopo 1 anno, fatto il defrag (deframmentazione segnava 22%), la WA non è salita che del 10%. Il mese dopo era programmato, segna deframmentazione 2% e... ninete, WA non sale.
Insomma, il defrag fatto assiduamente su un ssd poco frammentato ha un costo in scritture irrisorie.

Black (Wooden Law)
14-04-2025, 20:37
L'immagine fà un confronto di prestazioni, a parità di condizioni, R8 elabora più dati per ciclo: frequenza massima e quindi aumento delle prestazioni (33%).
Morfologicamente è di quasi il 60% più grande ed è, come fai notare, anche più energivoro (+26%) a parità di operazioni elaborate.
Si tratta però di efficienza per operazione, tu invece considera che la velocità operativa dell'R8 è migliore e quindi che le operazioni saranno più brevi con risparmio di tempo/energia.
A rafforzare questo dato è il sistema di implementazione fornito al Cortex R8, che nei white paper trovi sotto la voce scalabilità.
I core possono anche essere eseguiti in modo asimmetrico e ciascuno ha un proprio piano di alimentazione, il che significa che possono essere disattivati ​​per risparmiare energia.
L'area del processore, la frequenza e il consumo energetico dipendono fortemente dal processo, dalle librerie e dalle ottimizzazioni.
Questa flessibilità permette di distribuire il carico su più core, riducendo ulteriormente il tempo totale di elaborazione per carichi parallelizzabili e, di conseguenza, migliorando l’efficienza energetica complessiva.

Sembra quasi un paradosso ma mi sembra sensato il tuo ragionamento; tu dici: "insieme, data la maggior potenza, i core ARM Cortex-R8 consumano di più, ma grazie a diverse migliorie intelligenti si possono far lavorare di meno (o zero) alcuni core salvaguardando sul consumo energetico", giusto?

@Liupen
15-04-2025, 13:37
Sembra quasi un paradosso ma mi sembra sensato il tuo ragionamento; tu dici: "insieme, data la maggior potenza, i core ARM Cortex-R8 consumano di più, ma grazie a diverse migliorie intelligenti si possono far lavorare di meno (o zero) alcuni core salvaguardando sul consumo energetico", giusto?

Esattamente. Sarà una gestione sicuramente migliore per gli smartphone.
Per i controller degli ssd, questa funzione - penso io, si dovrà vedere - sarà purtroppo meno evidente e quindi meno efficiente.

Un Cortex R8 in un ssd durante l'uso (non idle), essendo sempre pesante per un controller nvme, offrirà sempre i 4 core attivi per massimizzare le performance.
Come dice la scheda, alla fine dipenderà da cosa fà al momento la cpu, utilizzare il 33% di potenza in più per contrastare il 26% di efficienza per operazione in meno... tipo per elaborare 10 thread un R5 impiega 10 secondi e 460 DMIPS/mW mentre un R8 per elaborare gli stessi 10 Thread impiega 6,7 secondi con una efficienza di 416 DMIPS/mW.
Tra questo, ed un po di risparmio per via della gestione dei core magari per le operazioni in background...

aled1974
15-04-2025, 15:23
Ma come non ti ricordi?
Non avevi il Samsung se no saresti stato li a scaricare e fare questo software per vedere l'età dei dati statici in relazione alla velocità di lettura :read: https://www.majorgeeks.com/files/details/ssd_read_speed_tester.html


Windows la situazione da qualche versione in qua è questa:
Ottimizza è un comando TRIM
La funzione programmabile sotto è - anche per gli ssd - un vero e proprio defrag.

Come mi sembra anche detto più volte da s12a, la deframmentazione negli ssd è periodicamente necessaria per mantenere i tempi di ricerca dei dati nei parametri; troppa deframmentazione (senza arrivare ai limiti dell'ingestibilità) fà lavorare di più il controller.
Dite le riscritture?
Balle! E' stata una delle cose che ho testato su un ssd, perchè richiede veramente poco: scritto un ssd sata da 500GB per il 30% dopo 1 anno, fatto il defrag (deframmentazione segnava 22%), la WA non è salita che del 10%. Il mese dopo era programmato, segna deframmentazione 2% e... ninete, WA non sale.
Insomma, il defrag fatto assiduamente su un ssd poco frammentato ha un costo in scritture irrisorie.

parrà strano e benchè non credo debba giustificarmi in alcun modo dico due cose se mai fregherà qualcosa a qualcuno….

la vita fuori da questo spazio online non è “rosa e fiori” purtroppo, in famiglia abbiamo tutti e 4 i genitori con problemi di salute che vanno dal moderatamente grave al gravissimo…. dal 2015….

ultima nostra vacanza? tre giorni a circa 70km da casa nel 2019…. si lavora da lunedì al sabato e la domenica si lavora ognuno a casa dei propri genitori

e questo prima ancora dell’embolia e infarto polmonari, causa covid (sai i negazionisti….), di mia moglie….



figurarsi se già con "le sole" tante problematiche mediche da ricordare e seguire abbia anche i neuroni per ricordarmi se un ssd (che non avevo, essendo “nato” con il 850evo nel 2016) richiedeva la sola riscrittura o anche un secure erase….

quindi se non ricordo scrivo “non me lo ricordo” :boh:




ottimizza è un comando trim? mi pare di averlo scritto a mia volta

funzione programmabile? mi riferivo alla frequenza con cui windows opera “ottimizza ssd”

defrag necessario? non mi sembra di aver parlato di defrag, che tanto per parlare, faccio a mia volta manualmente alcune volte l’anno. Solo che invece di affidarmi allo strumento integrato windows preferisco (a sentimento) eseguire con Defraggler (na volta il quick-def, n’altra il full-def). E chissene della possibile usura

balle riscrittura? non mi riferivo al defrag ma ad una vera lettura e riscrittura di tutti i dati presenti sugli ssd secondari/esterni dove al di la della trimmata (“ottimizza ssd” di windows) ed un eventuale defrag, gli algoritmi GC-WL non lavorano in sincrono con l’OS (almeno, la ricordo così con w10, con w11 non so se sia cambiato qualcosa… ne se sto ricordando male e basta ;) )

e in questo ultimo aspetto, a ragione o a torto, uso un paio di volte l’anno un programma che si chiama DiskFresh sul 860evo interno secondario e sui due ssd esterni che utilizzo come dischi di backup (assieme ad un meccanico sul quale opero diversamente ancora). Inutile? Eccesso di paranoia? Pazienza, i dati dentro sono importanti, preferisco un passaggio in più ed un’usura un po’ maggiore con la sicurezza di dormire sereno che tutti i backup sono ripristinabili alla bisogna

:mano:

ciao ciao

Black (Wooden Law)
15-04-2025, 16:40
Esattamente. Sarà una gestione sicuramente migliore per gli smartphone.
Per i controller degli ssd, questa funzione - penso io, si dovrà vedere - sarà purtroppo meno evidente e quindi meno efficiente.

Un Cortex R8 in un ssd durante l'uso (non idle), essendo sempre pesante per un controller nvme, offrirà sempre i 4 core attivi per massimizzare le performance.
Come dice la scheda, alla fine dipenderà da cosa fà al momento la cpu, utilizzare il 33% di potenza in più per contrastare il 26% di efficienza per operazione in meno... tipo per elaborare 10 thread un R5 impiega 10 secondi e 460 DMIPS/mW mentre un R8 per elaborare gli stessi 10 Thread impiega 6,7 secondi con una efficienza di 416 DMIPS/mW.
Tra questo, ed un po di risparmio per via della gestione dei core magari per le operazioni in background...

Beh per ora le valutazioni non sono troppo negative, l’SM2508 fa 9 W di picco contro i 12 W dell’E26 con ARM Cortex-R5. Se paragonassimo l’SM2508 al MAP1806 il primo perderebbe lo scontro, ma è DRAM-less l’SM2508? No, invece il MAP1806 sì. E penso che manco il paragone SM2508-E26 sia troppo corretto visto che quest’ultimo è uscito come primo controller per i PCIe 5.0 e quindi ha avuto molta meno preparazione rispetto all’SM2508. Mi piacerebbe dire “aspettiamo i prossimi controller ARM Cortex-R5” ma penso che non usciranno più visto l’E28.

@Liupen
15-04-2025, 19:14
@aled1974

Porca paletta potrebbe andarti meglio! Figlio unico anche tu?
Almeno riguardo i genitori, sono anch'io nella tua situazione, visto che ho una certa..


La domanda poteva essere retorica o meno, ma credimi, assolutamente innocua.
Ovvio che non avendo avuto un 840 / 840 evo, chisse...

Mi sono ricordato (per me con una certa ingenuità) quando nel 2015 erano partite decine di discussioni e test per capire se il proprio Samsung soffrisse del "bug" che - con terrore - poteva fare perdere i dati.
Il firmware con refresh fu pubblicato parecchio dopo.


Se ho travisato le tue parole, quando citavi WA GC in funzione del TRIM, chiedo scusa.
A volte parto per la tangente con ragionamenti concatenati (almeno nella mia testa :D ).
Comunque se l'argomento è "Ottimizza SSD" in Windows, non penso di aver scritto a vanvera!
Ho cercato solo di chiarire - a chi fosse interessato - il rapporto Windows/TRIM/deframmentazione/GC/WA.
Molti credono che Windows trimmi solo gli ssd (con la pianificazione attiva), invece...

La riscrittura del contenuto degli ssd come dici, periodica?
Come vedi non mi ero espresso. Ognuno prende gli accorgimenti che lo fanno stare più tranquillo, ci mancherebbe!
Io uso un nas in mirroring + backup manuale su hdd (emh...quando mi ricordo). Poi vero...internamente al pc ormai solo SSD.



Beh per ora le valutazioni non sono troppo negative, l’SM2508 fa 9 W di picco contro i 12 W dell’E26 con ARM Cortex-R5. Se paragonassimo l’SM2508 al MAP1806 il primo perderebbe lo scontro, ma è DRAM-less l’SM2508? No, invece il MAP1806 sì. E penso che manco il paragone SM2508-E26 sia troppo corretto visto che quest’ultimo è uscito come primo controller per i PCIe 5.0 e quindi ha avuto molta meno preparazione rispetto all’SM2508. Mi piacerebbe dire “aspettiamo i prossimi controller ARM Cortex-R5” ma penso che non usciranno più visto l’E28.

:cincin: senz'altro i paragoni ormai si attesteranno tra SM2508, E28, S4LY027 e ACNT093.
E poi ci saranno i DRAMless... Maxio vs Samsung?!

ARM è alla seconda versione dell'R8 (R82 si chiama forse), ma non più gli R5.
Potenza di calcolo multipla serve per (argomento attuale) le HBM delle AI.

PS. Lette le news? Cina chiude le forniture.

Black (Wooden Law)
15-04-2025, 19:37
ACNT093

Sì beh, a patto che SK hynix si decida a rilasciare 'sto cavolo di P51 in progettazione da non so quanto. :stordita:
Mi viene il dubbio che SK hynix abbia qualche problema con l'Alistar o con le NAND flash V8 (238L), però boh, spero di no, anche perché dalle recensioni (https://www.youtube.com/watch?v=PTiaEqAE5aE) è chiaramente un Gen5 di fascia alta.

piwi
17-04-2025, 07:39
Salve. Essendo in "progettazione" nuovo PC, che sostituisca PC1 in firma, pensavo di riorganizzare lo spazio. Situazione di partenza, un Crucial P5 con OS ed alcuni dati di dimensioni ristrette, soggetto a rapidi backup periodici; il grosso dei dati - giochi, una directory per retrogaming, audio ed altri dati archiviati per accesso non frequente, VM, spazio di lavoro per un leggero editing video, etc. su un array Raid-0 di dischi rotanti; questo, premesso che i dati "compressi" sono già tutti in copia altrove, ha un backup meno frequente. L'idea sarebbe quella di spostare OS ed altre cartelle con software - giochi, retrogaming - su un SSD NVME taglio 4 TBytes (diviso in due partizioni più quelle di "sistema" di Windows) e lasciare i dati ad accesso non frequente su un SSD SATA di larghe dimensioni che già possiedo. Con questa soluzione potrei semplificare il backup facendo in una botta sola la copia dell'unità con OS, documenti importanti, dati soggetti a frequenti modifiche e qualunque software sia installato. Mi servirebbe però un SSD davvero buono, non per velocità di picco, quanto per affidabilità e per reggere senza esitazioni la marea di scritture e letture generate dalla normale attività del OS (aggiornamenti, etc.) congiuntamente all'uso di un gioco o altro. Potrei prendere un Samsung 990 Pro, oppure c'è di meglio in ambito "consumer" ?

giovanni69
17-04-2025, 12:55
no, piazzo l'ssd al posto del vecchio e il vecchio finisce in pattumiera

..o meglio usalo come backup del nuovo SSD se non ci hai ancora pensato...

giovanni69
17-04-2025, 12:58
Mi servirebbe però un SSD davvero buono, non per velocità di picco, quanto per affidabilità e per reggere senza esitazioni la marea di scritture e letture generate dalla normale attività del OS (aggiornamenti, etc.) congiuntamente all'uso di un gioco o altro. Potrei prendere un Samsung 990 Pro, oppure c'è di meglio in ambito "consumer" ?

Piwi, il Samguns 990 Pro è abbastanza 'affidabile' visto che la Samsung degli SSD è diversa da quella dei NVMe?

Black (Wooden Law)
17-04-2025, 14:41
Mi servirebbe però un SSD davvero buono, non per velocità di picco, quanto per affidabilità e per reggere senza esitazioni la marea di scritture e letture generate dalla normale attività del OS (aggiornamenti, etc.) congiuntamente all'uso di un gioco o altro. Potrei prendere un Samsung 990 Pro, oppure c'è di meglio in ambito "consumer" ?

Hai un’idea di quante scritture ci fai sull’SSD? Proprio in termini quantitativi dico, perché io ritengo che gli attuali NVMe di fascia alta DRAM-based e TLC almeno 1PB di scritture le reggono tutte (per i tagli da 1+TB ovviamente) ma se dovessi programmare davvero tanti dati in poco tempo come nel caso di Anubbio in questo (https://www.hwupgrade.it/forum/showthread.php?t=3016527) post forse sarebbe meglio orientare la scelta su SSD consumer pSLC o con NAND flash di alta durata.

Sull’affidabilità, comunque, la mia opinione rimane la stessa di quel post: 9100 PRO, 990 PRO, 980 PRO > Crucial T500 > Phison E18 con Micron 176L TLC (B47R) > SK hynix P41 > WD SN850X, semplicemente perché le NAND flash Samsung sono quelle con la miglior incisione, le Micron insieme a quelle Samsung hanno la miglior architettura e poi ci sono quelle SK hynix e Kioxia che sono leggermente peggiori. Se però ci aggiungiamo gli SSD PCIe 5.0 (tralascia il 9100 PRO) lì il discorso cambia, quegli SSD avendo un controller più recente hanno un ECC più aggiornato e quindi più affidabile, ma dipende dal controller e tanti altri fattori, infatti meglio aspettare prima di tirare decisioni troppe affrettate.

frafelix
17-04-2025, 14:52
Aggiungo che se la vm la usi parecchio:
1 - meglio spostarla su ssd, decisamente più veloce tutta la gestione, sopratutto gli snapshot
2 - le vm scrivono abbastanza su disco, se non mi ricordo male

Nicodemo Timoteo Taddeo
17-04-2025, 14:53
Piwi, il Samguns 990 Pro è abbastanza 'affidabile' visto che la Samsung degli SSD è diversa da quella dei NVMe?

Ho letto e riletto più volte questa domanda ma continuo a non capirla :confused:

Black (Wooden Law)
17-04-2025, 15:04
Ho letto e riletto più volte questa domanda ma continuo a non capirla :confused:

Penso che intenda dire “dal momento che gli SSD Samsung enterprise sono diversi e migliori rispetto agli SSD Samsung consumer, il 990 PRO è abbastanza affidabile per quello che ci devi fare?”.

piwi
17-04-2025, 16:20
Riguardo l'ultima frase che ho scritto, intendevo ... "rimanendo in ambiente
consumer"; non avevo valutato l'ipotesi di acquistare prodotti di fascia superiore, però se per qualcosina in più la sicurezza dei dati e le prestazioni aumentano, ci posso pensare.

Non faccio un uso intensivo del PC ... E' acceso almeno sei ore al giorno, a volte anche solo per sentire la musica. Le VM non sono soggette ad uso intensivo. Giochi ... generalmente, uno per volta, gli altri rimangono "appesi". Editing video prevede per lo più conversioni tra formati. Occasionalmente, utilizzo video non compresso, ma per quello userei un disco rotante. Mi premono la longevità, l'affidabilità, il bilanciamento con gli altri componenti previsti - piattaforma AM5 - ... vorrei far durare il prossimo PC almeno un decennio. Anche oltre, magari come PC secondario.

Come OS, ad oggi installerei un Windows LTSC, quindi gli aggiornamenti dovrebbero essere per lo più quelli mensili e non quelli costanti delle "apps", i quali - lo vedo a lavoro - letteralmente corrodono gli SSD di fascia bassa, scrivendo su disco per ogni singolo utente.

Black (Wooden Law)
17-04-2025, 16:43
Non faccio un uso intensivo del PC ... E' acceso almeno sei ore al giorno, a volte anche solo per sentire la musica. Le VM non sono soggette ad uso intensivo. Giochi ... generalmente, uno per volta, gli altri rimangono "appesi". Editing video prevede per lo più conversioni tra formati. Occasionalmente, utilizzo video non compresso, ma per quello userei un disco rotante. Mi premono la longevità, l'affidabilità, il bilanciamento con gli altri componenti previsti - piattaforma AM5 - ... vorrei far durare il prossimo PC almeno un decennio. Anche oltre, magari come PC secondario.

Come OS, ad oggi installerei un Windows LTSC, quindi gli aggiornamenti dovrebbero essere per lo più quelli mensili e non quelli costanti delle "apps", i quali - lo vedo a lavoro - letteralmente corrodono gli SSD di fascia bassa, scrivendo su disco per ogni singolo utente.

Da come me ne parli mi sembra di vedere un uso assolutamente normale e non troppo intensivo, quindi sicuramente alla portata di un SSD come il Fury Renegade (https://www.amazon.it/Kingston-Renegade-Ideali-gamer-appassionati/dp/B09K3PSWD2/ref=sr_1_2?__mk_it_IT=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3LUA56ELSLZ5O&dib=eyJ2IjoiMSJ9.9JRDOz-zpurvq7BcNfJo2Prt9Zzqwh_eXMRVPZxDMUYijxe8_kMq1I6t20hpBZFwjydqOyP-RAXODiwswUX-7CsVJZglh1xvFRIDcclxfexQXC3890jR4gsF0Rx3KUsqYsQltkBqv-8imJy4HzIOzia-FoFmlp1tHj2GBCZqEENtzieA3t9BVI9o1uDHVYYZ4fNLgVqzJwEGzIjv3XeaT73uTq9D5bL6gk4ZeiSCleIJQzOQD3gg-xCh5cZGBr_vGH-F50jgFzqTvxwF1XiMhoSwhokk1Mlodyik7wnTArnTv6cDhfH9KSW75WuTi5BEuj1SQDjnxkm9_fIwLf0RSZG82l9xX5ylu3HSGuvFYfDZCFsO66m29JBkSuDyfh9QCqd583xwv271WU-wHmRy6I5lE-fTMyljDG62bxmDbMnex7axCMPyl7Y2pNh8Yucx.SYJt4cfClVRdeU6oT5bsJIbHNlTX1opP0thhLpFN0fU&dib_tag=se&keywords=Kingston%2BFury%2BRenegade&qid=1742836515&sprefix=kingston%2Bfury%2Brenegad%2Caps%2C97&sr=8-2&th=1).

giovanni69
17-04-2025, 16:47
Penso che intenda dire “dal momento che gli SSD Samsung enterprise sono diversi e migliori rispetto agli SSD Samsung consumer, il 990 PRO è abbastanza affidabile per quello che ci devi fare?”.
Esatto..:mano: con l'aggiunga che abituati all'affidabilità, performance dei SATA di un tempo di Samsung, in tempi più recenti, i loro NVMe non sono stati abbastanza all'altezza delle aspettative da leader di settore.



Come OS, ad oggi installerei un Windows LTSC, quindi gli aggiornamenti dovrebbero essere per lo più quelli mensili e non quelli costanti delle "apps", i quali - lo vedo a lavoro - letteralmente corrodono gli SSD di fascia bassa, scrivendo su disco per ogni singolo utente.

Davvero?:eek: ! Mai pensato che le versioni consumer/pro di Windows fossero così ...usuranti.
Che cosa riscontri su quegli SSD, al lavoro?

piwi
17-04-2025, 19:17
Da come me ne parli mi sembra di vedere un uso assolutamente normale e non troppo intensivo

Grazie !



Che cosa riscontri su quegli SSD, al lavoro?

Su una decina, forse meno, dei più anziani PC, gli HDD rotanti sono stati sostituiti in "autonomia" con SSD; prodotti di fascia bassa ma non proprio il peggio del peggio, come Kingston A400. Questi PC sono in uso abituale, mediamente, a due o tre utenti, che si susseguono; ma vi hanno accesso anche occasionale altri dipendenti. Per ogni utente, autorizzato a livello di dominio, è creato il profilo; ho notato che subito dopo le aperture del profilo il sistema è fortemente sfruttato dai servizi di aggiornamento APPS. Questo si percepisce perchè sono macchine con configurazioni misere; con l'HDD rotante questo evento letteralmente rende inutilizzabile la macchina. Considerato che i PC si usano moltissimo per applicativi Web, molto con Word, poco con Excel e pochissimo per tutto il resto ... Per il consumo delle unità, percepibile in particolare su macchina con un numero di utenti pari a diverse decine, tendo a dare parte della responsabilità alle attività del OS.

sbaffo
17-04-2025, 19:20
ricollegandosi al discorso jedec di qualche tempo fa, ecco una prova poco professionale ma questo passa al convento :D :
https://www.tomshw.it/hardware/non-alimentare-regolarmente-gli-ssd-potrebbe-farvi-perdere-i-dati-2025-04-16

spoiler: dopo due anni spenti alcuni SSD abbastanza usati e di scarsa qualità perdono qualche dato, quelli nuovi e buoni riescono a recuperarli ma lo smart segnala qualche difficoltà. +o-

Black (Wooden Law)
17-04-2025, 22:14
ricollegandosi al discorso jedec di qualche tempo fa, ecco una prova poco professionale ma questo passa al convento :D :
https://www.tomshw.it/hardware/non-alimentare-regolarmente-gli-ssd-potrebbe-farvi-perdere-i-dati-2025-04-16

spoiler: dopo due anni spenti alcuni SSD abbastanza usati e di scarsa qualità perdono qualche dato, quelli nuovi e buoni riescono a recuperarli me lo smart segnala qualche difficoltà. +o-

Interessante come test. Peccato soltanto che gli SSD siano dei JS600, quindi SSD di bassa qualità, presumo. Sta di fatto che sarebbe stato interessante fare lo stesso test su SSD NVMe recenti che hanno un ECC migliore.

giovanni69
18-04-2025, 07:35
E questi interventi ECC cumulativi, come controllare se hanno fatto il loro dovere oppure comunque hanno comportato perdita di dati?

Semplicemente è tutto a posto perchè gli ECC falliti sono 0?

https://i.postimg.cc/XYqgK0g8/SMART-2025-04-18-07-32-22.png (https://postimg.cc/nX87Zggj)

https://i.postimg.cc/4xcYRL4G/Smart-HD-Sentinel-2-2025-04-18-07-38-55.png (https://postimages.org/)

Black (Wooden Law)
18-04-2025, 12:06
E questi interventi ECC cumulativi, come controllare se hanno fatto il loro dovere oppure comunque hanno comportato perdita di dati?

Semplicemente è tutto a posto perchè gli ECC falliti sono 0?

Secondo me è tutto a posto e il parametro S.M.A.R.T. “ECC corretti cumulativi” indica le correzioni degli errori dei dati fatti tramite ECC mentre il parametro “ECC falliti” le volte in cui l’ECC ha fallito. Quindi qui l’SSD ti sta dicendo “ho corretto 587.312 bit senza mai fallire una volta”. Devo dire, però, che questa è la prima volta che vedo questi parametri nello S.M.A.R.T. di un SSD, quindi non son sicuro al 100% di quello che dico (anche se a logica è così).

Comunque, per dare un po’ di contesto in più, l’ECC è il codice di correzione degli errori di un SSD e può essere o BCH o LDPC. L’ECC è quindi necessario per rilevare e correggere gli errori. BCH è più vecchio e meno potente dell’LDPC ed è infatti in disuso.

Quando un SSD scrive una pagina la divide in più chunk di memoria. Per ogni chunk l’ECC genera un codeword, ossia dei bit in più ai bit “normali” che sono ridondanti e che servono per la rivelazione e correzione degli errori. Quindi il chunk di memoria più i bit ridondanti si chiama “codeword”. Più è grande il codeword più “forte” sarà l’ECC dal momento che la forza di protezione di un ECC è data dal coding rate, ossia il rapporto tra la dimensione dei chunk e la dimensione dei codeword. Ora la dimensione tipica del codeword LDPC nei nuovi controller è di 4kB, una volta era 2kB e 1kB. Al di sotto del kB, se ricordo bene, c’era soltanto il BCH.

Coding rate e la lunghezza del codeword formano insieme la capacità di correzione degli errori di un ECC, ossia il numero massimo di errori di bit grezzi (RBER in inglese) che l’ECC può correggere. Quando il RBER è troppo alto l’ECC fallisce.

frafelix
18-04-2025, 14:03
Bella spiegazione, direi altra cosa da prima pagina

sbaffo
18-04-2025, 16:12
Interessante come test. Peccato soltanto che gli SSD siano dei JS600, quindi SSD di bassa qualità, presumo. Sta di fatto che sarebbe stato interessante fare lo stesso test su SSD NVMe recenti che hanno un ECC migliore. Si, però erano almeno TLC, qiindi non scarsissimi, sempre meglio dei QLC suppongo.

E questi interventi ECC cumulativi, come controllare se hanno fatto il loro dovere oppure comunque hanno comportato perdita di dati?

Semplicemente è tutto a posto perchè gli ECC falliti sono 0?
....
Se ti riferisci a quelli del mio link, avevano copiato gli hash per confrontarli coi file "recuperati" ed essere sicuri che fossero integri. Suppongo che l' ECC abbia un sistema simile per dire se sono riusciti o falliti.

@Liupen
18-04-2025, 16:21
ricollegandosi al discorso jedec di qualche tempo fa, ecco una prova poco professionale ma questo passa al convento :D :
https://www.tomshw.it/hardware/non-alimentare-regolarmente-gli-ssd-potrebbe-farvi-perdere-i-dati-2025-04-16

spoiler: dopo due anni spenti alcuni SSD abbastanza usati e di scarsa qualità perdono qualche dato, quelli nuovi e buoni riescono a recuperarli me lo smart segnala qualche difficoltà. +o-

La prenderei come una buona notizia. Prima di tutto gli ssd (mai sentito questo produttore) nuovi mantengono il dato dopo 2 anni. Secondo gli ssd stimati per contenere 60 TB di dati sono arrivati a 280 TB, questo la dice lunga sulle possibilità degli ssd.
Il fatto che un ssd scritto tanto perda poi i dati dopo sue anni, anche in questo caso supera le aspettative, perchè il limite minimo imposto da Jedec è di 1 solo anno.

E questi interventi ECC cumulativi, come controllare se hanno fatto il loro dovere oppure comunque hanno comportato perdita di dati?

Semplicemente è tutto a posto perchè gli ECC falliti sono 0?



Si. Ora lo smart con gli nvme non è così capillare da dirti tutto questo.
Anzi sono sempre più ermetici.

frafelix
18-04-2025, 16:23
Anni fa (10?) c'erano dei tizi su un forum estero (forse extreme hardware) che facevano gli endurance test con gli ssd e li facevano scrivere a oltranza finché non morivano. Erano i tempi dei sandforce e gli intel x25m!

giovanni69
18-04-2025, 17:59
Grazie @Black (Wooden Law) (concordo che possa essere materiale per prima pagina). Davvero interessante!
@Liupen -- ok, bene. Insomma quell'Asenno AS25, almeno ha uno smart decente (a parte il parametro bloccato della temperatura).

@sbaffo: no, mi riferivo allo smart del mio Asenno.

Black (Wooden Law)
18-04-2025, 18:32
Bella spiegazione, direi altra cosa da prima pagina
Grazie @Black (Wooden Law) (concordo che possa essere materiale per prima pagina). Davvero interessante!

Grazie ragazzi, ho pensato di scrivere un po’ dell’ECC in prima pagina ma ho sempre creduto che fosse una cosa troppo tecnica e inutile per il consumatore medio (mentre WL, GC e WAF sono più basilari come concetto e soprattutto si leggono dovunque). A ‘sto punto, se mi dite così, ci lavoro su e metto informazioni aggiuntive a riguardo.

Anni fa (10?) c'erano dei tizi su un forum estero (forse extreme hardware) che facevano gli endurance test con gli ssd e li facevano scrivere a oltranza finché non morivano. Erano i tempi dei sandforce e gli intel x25m!

Qui (https://3dnews.ru/938764) c’è il canonico test stravisto di 3DNews. 7,7PB il 900P da 280GB e più di 25.000 PEC… :sofico:

sbaffo
18-04-2025, 19:36
@Liupen -- ok, bene. Insomma quell'Asenno AS25, almeno ha uno smart decente (a parte il parametro bloccato della temperatura).

@sbaffo: no, mi riferivo allo smart del mio Asenno. Azz, se il tuo ssd ha tutti quegli errori io non starei trenquillo anche se finora è riuscito a correggerli, un domanio potrebbe peggiorare ancora e non riuscirci più...
Lo smart vale nulla, se non ricordo male eri proprio tu che avevi postato risultati di smart tornati buoni dopo cali disastrosi... a quanto ricordo lo smart segna più che altro la tendenza, se il disastro si ferma torna buono, ma non mi fiderei molto...

@Liupen
18-04-2025, 20:42
Non si può dire; magari è normale per quel modello di ssd.
Dal grafico mi sembra che inizi a salire da subito, mentre se dipendesse dalla vetustità delle celle, ci sarebbe un picco da un certo punto in poi.
(Dico io ipotizzando).

Black (Wooden Law)
18-04-2025, 23:39
Lexar annuncia l’NQ780 (https://www.lexar.com/global/products/Lexar-NQ780-M-2-2280-PCIe-Gen-4x4-NVMe-SSD/), un SSD Gen4 probabilmente QLC (anche se l’EQ790 - che si chiamava all’inizio “NQ790” - all’inizio è stato lanciato con NAND flash YMTC 128L TLC) ma DRAM-less con un controller 8 canali.

Che controller potrebbe mai essere tenendo conto che l’SSD è cinese e non ci sono controller a 8 canali DRAM-less? Forse l’InnoGrit IG5236, che inizialmente è sempre stato DRAM-based, ma ora su qualche SSD è DRAM-less (KingSpec XG7000 4TB (https://www.techpowerup.com/ssd-specs/kingspec-xg7000-4-tb.d2337)). Il motivo per il quale sia diventato DRAM-less magari è perché lo stato “MN-5236” era dovuto da qualche errore con la DRAM, chi lo sa. Sta di fatto che penso sia uno dei controller peggiori in commercio per l’affidabilità.

sbaffo
19-04-2025, 12:54
Non si può dire; magari è normale per quel modello di ssd.
Dal grafico mi sembra che inizi a salire da subito, mentre se dipendesse dalla vetustità delle celle, ci sarebbe un picco da un certo punto in poi.
(Dico io ipotizzando). Neanche io so spiegare, ma a occhio c'erano parecchie celle "guaste" (scarsa qualità? selezione alla cinese? boh), ora si sono esaurite perciò il trend si è fermato... si spera.
Sembra che il disastro si avvenuto durante il terzo anno, tra gen 2021 e feb 22, magari era montato male il cavo o alimentazione ballerina o chi lo sa, solo gio69 può ipotizzarlo.
Quello che non sappiamo è se sono state usate le celle riservate all'over provisioning o no, e quante ne restano...
vabbè è solo per speculare per divertimento, su un Asenno spero non ci siano dati importanti.:D

giovanni69
19-04-2025, 15:28
Azz, se il tuo ssd ha tutti quegli errori io non starei trenquillo anche se finora è riuscito a correggerli, un domanio potrebbe peggiorare ancora e non riuscirci più...
Lo smart vale nulla, se non ricordo male eri proprio tu che avevi postato risultati di smart tornati buoni dopo cali disastrosi... a quanto ricordo lo smart segna più che altro la tendenza, se il disastro si ferma torna buono, ma non mi fiderei molto...

Avevo postato problemi ad un HDD circa bad blocks corretti, non il meccanismo di correazione ECC.

Non si può dire; magari è normale per quel modello di ssd.
Dal grafico mi sembra che inizi a salire da subito, mentre se dipendesse dalla vetustità delle celle, ci sarebbe un picco da un certo punto in poi.
(Dico io ipotizzando).

In effetti :mbe: ci sarebbe una sorta di picco o meglio relativo plateau negli ultimi 3 anni (2022-2025), spaziatura temporale delle rilevazioni a parte :

https://i.postimg.cc/4xcYRL4G/Smart-HD-Sentinel-2-2025-04-18-07-38-55.png (https://postimages.org/)


vabbè è solo per speculare per divertimento, su un Asenno spero non ci siano dati importanti.:D

Nah! funziona su un notebook in cui non ci sono quasi mai dati nuovi ed ovviamente ho comunque un clone sempre pronto. Ma questo non toglie che anche gli SSD enteprise abbiano il loro clone & backup :)
P.S: Tra l'altro ho anche l'Asenno AS25 in versione 250 GB ma non è in uso da tempo.

giovanni69
19-04-2025, 15:43
Sembra che il disastro si avvenuto durante il terzo anno, tra gen 2021 e feb 22, magari era montato male il cavo o alimentazione ballerina o chi lo sa, solo gio69 può ipotizzarlo.

Non lo ipotizzo perchè allora ci sarebbero errori UltraDMA CRC errors che continuano ad essere 0.
L'andamento iniziale ECC 2019/2020 è stato questo:
https://i.postimg.cc/xj6Nq8Z8/Cumulative-Correct-ECC-2020-03-29-19-45-52.jpg (https://postimages.org/)

Successivamente fino al 2022:
https://i.postimg.cc/gk5wq5mP/2022-08-31-18-18-23-cumulative-corrected-ECC.jpg (https://postimages.org/)

Black (Wooden Law)
19-04-2025, 18:43
Neanche io so spiegare, ma a occhio c'erano parecchie celle "guaste" (scarsa qualità? selezione alla cinese? boh), ora si sono esaurite perciò il trend si è fermato... si spera.

Perché pensi ci siano “parecchie celle guaste”?

sbaffo
19-04-2025, 19:14
Perché pensi ci siano “parecchie celle guaste”?
guaste nel senso poco affidabili/che davano errori/non mantenevano i valori scritti. Gio69 giustamente nota che non c'erano errori crc, quindi i problemi/errori dipendono dalle celle (o da qualche altro fattore che non sappiamo, in mancanza propenderei per dare la colpa alle celle, vista anche la dubbia qualità degli asenno).
Suppongo, ma non lo so, che dopo gli errori alcune (o molte) di esse siano state catalogate dal firmware come "bad sector" e rimpiazzate da quelle di riserva (over-provision), perciò hanno smesso di dare problemi.
Sono tutte soltanto supposizioni mie, per spiegare la strana curva del grafico ECC, che prima aumenta poi si ferma (una volta sostituite tutte le celle inaffidabili, suppongo).

certo che Gio ha una fortuna con gli Hdd/ssd :D

Edit, comparando i due smart noto qualche stranezza (il primo è quello più recente):
https://i.postimg.cc/XYqgK0g8/SMART-2025-04-18-07-32-22.png https://i.postimg.cc/xj6Nq8Z8/Cumulative-Correct-ECC-2020-03-29-19-45-52.jpg

- gli accessi non allineati sono altissimi :confused: in entrambi , cosa sarebbero? avevi fatto una clonazione da hdd senza allineamento? ormai lo fanno tutti in automatico ma magari nel 2019...
- media wearout indicator 62 nel secondo, stesso 62 nel primo ma senza spiegazione.
- settori riallocati ed eventi riallocazione zero, sembra smontare le mie supposizioni, ma blocchi errati totali 193 :confused:, sempre che siano dati affidabili.
- unexpected power loss da 13 a 52, forse è questo il motivo degli errori ecc allora.

pitx
19-04-2025, 21:00
Ecco, come si presenta il Lexar NS100 256GB
https://i.postimg.cc/vHW64stp/Crystal-Disk-Info-20250418215403.png https://i.postimg.cc/Gh0y32GF/Crystal-Disk-Mark-20250405153047.png https://i.postimg.cc/CLNkv0nb/Crystal-Disk-Mark-20250419213421.png

@Liupen
19-04-2025, 21:11
- gli accessi non allineati sono altissimi :confused: in entrambi , cosa sarebbero? avevi fatto una clonazione da hdd senza allineamento? ormai lo fanno tutti in automatico ma magari nel 2019...
- media wearout indicator 62 nel secondo, stesso 62 nel primo ma senza spiegazione.
- settori riallocati ed eventi riallocazione zero, sembra smontare le mie supposizioni, ma blocchi errati totali 193 :confused:, sempre che siano dati affidabili.
- unexpected power loss da 13 a 52, forse è questo il motivo degli errori ecc allora.

Mah! Alla fine mi sembra sempre più che siano dei "falsi positivi". Cioè cose segnalate nello smart ma che non hanno peso realmente sullo stato dell'ssd.

Ecco, come si presenta il Lexar NS100 256GB
https://i.postimg.cc/vHW64stp/Crystal-Disk-Info-20250418215403.png https://i.postimg.cc/Gh0y32GF/Crystal-Disk-Mark-20250405153047.png

Conforme ad un QLC scaruso (la cache di scrittura mantiene alte le prestazioni sequenziali ma quelle casuali sono basse).
Non sarà indicato come disco da OS, ma per il resto fa il suo.

Nicodemo Timoteo Taddeo
19-04-2025, 21:13
Ecco, come si presenta il Lexar NS100 256GB



Trovo inverosimile che a quasi 2300 ore di funzionamento risultano così poche letture e scritture sull'SSD... e sarebbe uno SSD con il sistema operativo Windows :eekk:

Come mai hai deciso di postare quell'immagine? È un SSD che hai comprato ora come nuovo o cos'altro?

pitx
19-04-2025, 21:28
Trovo inverosimile che a quasi 2300 ore di funzionamento risultano così poche letture e scritture sull'SSD... e sarebbe uno SSD con il sistema operativo Windows :eekk:

Come mai hai deciso di postare quell'immagine? È un SSD che hai comprato ora come nuovo o cos'altro?

Da moh che lo uso, Ordinato in data 24 maggio 2023

Appena ho tempo recupero il Sandisk SSD Plus 240GB S-Ata ��

Black (Wooden Law)
19-04-2025, 23:23
Mah! Alla fine mi sembra sempre più che siano dei "falsi positivi". Cioè cose segnalate nello smart ma che non hanno peso realmente sullo stato dell'ssd.

Concordo al 100%. Anche sul resto, il fatto che ci siano tante correzioni ed eventi ECC non vuol dire che c’è qualcosa che non va nell’SSD o nelle NAND flash, anche perché se fosse così (e quindi fosse una cosa seria) ci sarebbero sicuramente dei blocchi riallocati a causa di celle NAND flash difettose. Son sicuro che se i recenti SSD (sia SATA che NVMe) avessero S.M.A.R.T. così completo come questo Asenno vedremmo anche in loro una miriade di errori ECC corretti.

Sui “Blocchi errati totali” non sin sicuro di cosa voglia intendere ma penso che indica tutti i blocchi che hanno avuto errori ECC (che poi sono stati corretti, ovviamente).

Infine, media wearout indicatori (MWI) indica la percentuale S.M.A.R.T. 62 = 98% perché il 62 è in esadecimale. Non so se il MWI del primo Asenno è il parametro S.M.A.R.T. “E9”, ma in caso lo fosse potrebbe essere un bug si CrystaDiskInfo.

Nicodemo Timoteo Taddeo
20-04-2025, 13:12
Da moh che lo uso, Ordinato in data 24 maggio 2023

Quindi quei dati relativi alla letture e scritture sono sicuramente errati, non che ci fossero dubbi ma adesso v'è certezza. :)

Tra l'altro le righe Total Write e Total read dei dati SMART convertite in decimale dicono altro.

Al tuo posto proverei a vedere se è CDI a sbagliare per qualche motivo, userei HD Sentinel Professional portable per vedere se anche con lui viene mostrata questa "stranezza".

https://www.hdsentinel.com/download.php

pitx
20-04-2025, 13:46
Da moh che lo uso, Ordinato in data 24 maggio 2023

Appena ho tempo recupero il Sandisk SSD Plus 240GB S-Ata ��

Il vecchio Santodisco su USB
https://i.postimg.cc/85NSFXrT/Crystal-Disk-Info-20250420020309.png
https://i.postimg.cc/QMpDdZC6/Crystal-Disk-Mark-20250420020253.png

pitx
20-04-2025, 13:56
Quindi quei dati relativi alla letture e scritture sono sicuramente errati, non che ci fossero dubbi ma adesso v'è certezza. :)

Tra l'altro le righe Total Write e Total read dei dati SMART convertite in decimale dicono altro.

Al tuo posto proverei a vedere se è CDI a sbagliare per qualche motivo, userei HD Sentinel Professional portable per vedere se anche con lui viene mostrata questa "stranezza".

https://www.hdsentinel.com/download.php

https://i.postimg.cc/LsvyTxb9/HDS.png

Black (Wooden Law)
20-04-2025, 14:42
Il vecchio Santodisco su USB
https://i.postimg.cc/85NSFXrT/Crystal-Disk-Info-20250420020309.png
https://i.postimg.cc/QMpDdZC6/Crystal-Disk-Mark-20250420020253.png

25TB sulle NAND flash, 41TB dall’host, 119TB sulle NAND flash SLC, 107 PEC e un WAF di 0,6. Direi non male anche se CDI lo segna all’84%.

https://i.postimg.cc/LsvyTxb9/HDS.png

Bene o male gli stesso valori di CDI mi sembra di vedere, o è buggato lo S.M.A.R.T. o in qualche maniera ci hai scritto pochi GB.

pitx
20-04-2025, 16:01
25TB sulle NAND flash, 41TB dall’host, 119TB sulle NAND flash SLC, 107 PEC e un WAF di 0,6. Direi non male anche se CDI lo segna all’84%.

Non ricordo se monta un Silicon Image SN2246XT

https://i.postimg.cc/tJgN26ML/SM2246-XTvs-SM2246-EN.png


Bene o male gli stesso valori di CDI mi sembra di vedere, o è buggato lo S.M.A.R.T. o in qualche maniera ci hai scritto pochi GB.

Potrebbe essere la seconda...

Black (Wooden Law)
20-04-2025, 16:47
Il firmware in realtà sembra appartenere ad un controller Marvell, non ad uno Silicon Motion: https://smarthdd.com/database/SanDisk-SDSSDA240G/Z32070RL/. Possibile che usi il Marvell 88SS1074 come scritto da Tom’s Hardware, comunque, il SanDisk SSD Plus ha cambi di BOM da sempre:
The SanDisk SSD Plus 120GB we received from a third party uses the SM2246XT controller with SanDisk MLC NAND flash. The SSD Plus 240GB arrived with an SMI SM2256S controller and SanDisk MLC, as well. Last but not least, the SSD Plus 480GB is actually not a DRAMless SSD after all. It ships with the same Marvell 88SS1074 "Dean" controller found in the SanDisk X400. The controller comes paired with SanDisk MLC NAND and a Nanya DDR3 package.

Comunque quelle poche scritture sulle NAND flash TLC e il WAF di 0,6 è dovuto dalla cache SLC statica, non dal controller (in caso te lo chiedessi).

pitx
20-04-2025, 18:06
Il firmware in realtà sembra appartenere ad un controller Marvell, non ad uno Silicon Motion: https://smarthdd.com/database/SanDisk-SDSSDA240G/Z32070RL/. Possibile che usi il Marvell 88SS1074 come scritto da Tom’s Hardware, comunque, il SanDisk SSD Plus ha cambi di BOM da sempre:


Comunque quelle poche scritture sulle NAND flash TLC e il WAF di 0,6 è dovuto dalla cache SLC statica, non dal controller (in caso te lo chiedessi).

Monta un SM2256S
https://i.postimg.cc/c4Y3FyhR/IMG-20250420-175522.jpg https://i.postimg.cc/JzLkg6Y9/IMG-20250420-175529.jpg https://i.postimg.cc/L4Gfk6t4/IMG-20250420-175459.jpg
https://i.postimg.cc/GtTLhRtq/IMG-20250420-175512.jpg

Black (Wooden Law)
20-04-2025, 18:49
Monta un SM2256S
https://i.postimg.cc/c4Y3FyhR/IMG-20250420-175522.jpg https://i.postimg.cc/JzLkg6Y9/IMG-20250420-175529.jpg https://i.postimg.cc/L4Gfk6t4/IMG-20250420-175459.jpg
https://i.postimg.cc/GtTLhRtq/IMG-20250420-175512.jpg

Penso che siano delle NAND flash 2D anche se il controller (che è superobsoleto) può operare con NAND flash 3D. Su Flashinfo (https://flashinfo.top/FlashInfo?pn=05141-128G) non segna 2D o 3D, più probabile che sia la prima.

pitx
20-04-2025, 19:13
Penso che siano delle NAND flash 2D anche se il controller (che è superobsoleto) può operare con NAND flash 3D. Su Flashinfo (https://flashinfo.top/FlashInfo?pn=05141-128G) non segna 2D o 3D, più probabile che sia la prima.

At least a few end users earlier in the release cycle received drives with a Silicon Motion, Inc. (SMI) SM2246XT controller and MLC flash. More recently, users reported the SSD Plus came with the SMI SM2256S controller and TLC NAND. Some of the reports didn't specify which capacity.

The SanDisk SSD Plus 120GB we received from a third party uses the SM2246XT controller with SanDisk MLC NAND flash. The SSD Plus 240GB arrived with an SMI SM2256S controller and SanDisk MLC, as well. Last but not least, the SSD Plus 480GB is actually not a DRAMless SSD after all. It ships with the same Marvell 88SS1074 "Dean" controller found in the SanDisk X400. The controller comes paired with SanDisk MLC NAND and a Nanya DDR3 package.

Black (Wooden Law)
20-04-2025, 19:23
The SanDisk SSD Plus 120GB we received from a third party uses the SM2246XT controller with SanDisk MLC NAND flash. The SSD Plus 240GB arrived with an SMI SM2256S controller and SanDisk MLC, as well. Last but not least, the SSD Plus 480GB is actually not a DRAMless SSD after all. It ships with the same Marvell 88SS1074 "Dean" controller found in the SanDisk X400. The controller comes paired with SanDisk MLC NAND and a Nanya DDR3 package.

Potresti utilizzare il FID SMI per SATA: “SMI flash id(PATA,SATA,CF,SD) (vlo.name:3000/ssdtool/)”. Stessa roba con l’NS100 ma col tool “Marvell 88nv1120 flash id (SATA)”.

pitx
20-04-2025, 19:33
Potresti utilizzare il FID SMI per SATA: “SMI flash id(PATA,SATA,CF,SD) (vlo.name:3000/ssdtool/)”. Stessa roba con l’NS100 ma col tool “Marvell 88nv1120 flash id (SATA)”.

https://www.hardware-corner.net/ssd-database/SanDisk-SSD-Plus/
TLC by Kioxia...

NS100 256 monta Micron e chipset Maxio
v0.21a
Drive: 0(ATA)
Model: Lexar 128GB SSD
Fw : SN09610
Size : 122104 MB [128.0 GB]
Firmware id string[2D0]: MKSSD_200004000096100122,Aug 7 2021,14:20:46,MA1102,HC##C#1C
Project id string[280] : r:/1102_B47R_DW2.1_NO_SNAP_READ
Controller : MAS1102
NAND string : MT29F512G08EBLEE
NAND MaxPE cycles : 1500
Ch0CE0: 0x2c,0xc3,0x8,0x32,0xea,0x30,0x0 - Micron 176L(B47R) TLC 512Gb/CE 512Gb/die
Ch1CE0: 0x2c,0xc3,0x8,0x32,0xea,0x30,0x0 - Micron 176L(B47R) TLC 512Gb/CE 512Gb/die

JM/MK/MAS ID v0.24a by Ochkin Vadim
0: (Lexar SSD NS100 256GB
Please select drive number:0
Drive: 0(ATA)
Model: Lexar SSD NS100 256GB
Fw : SN12980
Size : 244198 MB [256.1 GB]
Firmware id string[2D0]: MKSSD_200018000129800122,Nov 28 2022,16:39:20,MA1102,EC##C#2C
Project id string[280] : r:/1102_B47R_DW2.1_2LUN_LP_ALL
Controller : MAS1102
NAND string : MT29F512G08EBLEE
NAND MaxPE cycles : 3000
Ch0CE0: 0x2c,0xc3,0x8,0x32,0xea,0x30,0x0 - Micron 176L(B47R) TLC 512Gb/CE 512Gb/die
Ch1CE0: 0x2c,0xc3,0x8,0x32,0xea,0x30,0x0 - Micron 176L(B47R) TLC 512Gb/CE 512Gb/die
Ch0CE2: 0x0,0x0,0x0,0x0,0x0,0x0,0x0 -
Ch1CE2: 0x0,0x0,0x0,0x0,0x0,0x0,0x0 -

Black (Wooden Law)
20-04-2025, 20:34
https://www.hardware-corner.net/ssd-database/SanDisk-SSD-Plus/
TLC by Kioxia...

Ecco, già che c’è scritto “N/A” sul numero di layer la fa lunga. NAND flash 2D, ne son sicuro.

NS100 256 monta Micron e chipset Maxio
v0.21a
Drive: 0(ATA)
Model: Lexar 128GB SSD
Fw : SN09610
Size : 122104 MB [128.0 GB]
Firmware id string[2D0]: MKSSD_200004000096100122,Aug 7 2021,14:20:46,MA1102,HC##C#1C
Project id string[280] : r:/1102_B47R_DW2.1_NO_SNAP_READ
Controller : MAS1102
NAND string : MT29F512G08EBLEE
NAND MaxPE cycles : 1500
Ch0CE0: 0x2c,0xc3,0x8,0x32,0xea,0x30,0x0 - Micron 176L(B47R) TLC 512Gb/CE 512Gb/die
Ch1CE0: 0x2c,0xc3,0x8,0x32,0xea,0x30,0x0 - Micron 176L(B47R) TLC 512Gb/CE 512Gb/die

JM/MK/MAS ID v0.24a by Ochkin Vadim
0: (Lexar SSD NS100 256GB
Please select drive number:0
Drive: 0(ATA)
Model: Lexar SSD NS100 256GB
Fw : SN12980
Size : 244198 MB [256.1 GB]
Firmware id string[2D0]: MKSSD_200018000129800122,Nov 28 2022,16:39:20,MA1102,EC##C#2C
Project id string[280] : r:/1102_B47R_DW2.1_2LUN_LP_ALL
Controller : MAS1102
NAND string : MT29F512G08EBLEE
NAND MaxPE cycles : 3000
Ch0CE0: 0x2c,0xc3,0x8,0x32,0xea,0x30,0x0 - Micron 176L(B47R) TLC 512Gb/CE 512Gb/die
Ch1CE0: 0x2c,0xc3,0x8,0x32,0xea,0x30,0x0 - Micron 176L(B47R) TLC 512Gb/CE 512Gb/die
Ch0CE2: 0x0,0x0,0x0,0x0,0x0,0x0,0x0 -
Ch1CE2: 0x0,0x0,0x0,0x0,0x0,0x0,0x0 -

Bene, sospettabile che usasse MaxioTech. Questi due SSD sono letteralmente la definizione di “binning”, comunque: il 128GB ha die da 1.500 PEC mentre il 256GB da 3.000 PEC (rispettivamente Mediagrade e FortisFlash come valutazione di Micron). Riferisco per il DB di TPU comunque, grazie Pitx.

pitx
20-04-2025, 23:33
Ecco, già che c’è scritto “N/A” sul numero di layer la fa lunga. NAND flash 2D, ne son sicuro.



Bene, sospettabile che usasse MaxioTech. Questi due SSD sono letteralmente la definizione di “binning”, comunque: il 128GB ha die da 1.500 PEC mentre il 256GB da 3.000 PEC (rispettivamente Mediagrade e FortisFlash come valutazione di Micron). Riferisco per il DB di TPU comunque, grazie Pitx.

Ci sono versioni col Marvell...
Ma io non le ho toccate con mano, sono come gli unicorni...

giovanni69
21-04-2025, 10:31
- gli accessi non allineati sono altissimi :confused: in entrambi , cosa sarebbero? avevi fatto una clonazione da hdd senza allineamento? ormai lo fanno tutti in automatico ma magari nel 2019...

Avevo sollevato la questione nel thread tempo fa ma non ne sono venuto fuori.
Credo che s12a avesse ipotizzato.
Non credo che c'entri la clonazione iniziale da HDD a SSD, visto che hanno continuato a salire anche successivamente.
Credo anche di aver effettuato un comando 'Align' con qualche software (forse... :old: Paragon Alignment Tool, previa clonazione di sicurezza su altro supporto) ma mi avevo risposto che non ce n'era bisogno.


certo che Gio ha una fortuna con gli Hdd/ssd :D

Beh, forse perchè sono dell'approccio 'test, don't guess'. E quell'HD Sentinel Pro è utile proprio per realizzare osservazioni dinamiche nel tempo. Comunque sfighe di HDD (vergini) a parte, sia con Samsung enterprise, un EVO e questi due Asenno, per ora, non ho mai perso dati (per quel che ne so). :sperem: :tie:

alefello
22-04-2025, 09:08
Ciao a tutti
Qual'è attualmente l'SSD con cache (DRAM o SLC) m.2 PCI-E (non importa la versione) da 500GB o 1TB più economico sul mercato (e magari che non sia di brand semi sconosciuti)?
O se mi dite che per un drive di sistema di un PC semplicemente da ufficio può andare bene anche senza cache, va bene anche quello.
Grazie mille

aled1974
22-04-2025, 09:36
"i soliti noti" li trovi a pagina 1 post #4 ;)

per mio esclusivo sentimento ssd di sistema ---> in ogni caso con dram

ma vedo che in ambito lavorativo spesso si opta per la soluzione più economica, a prescindere :fagiano:

ciao ciao

@Liupen
22-04-2025, 14:42
Bene, sospettabile che usasse MaxioTech. Questi due SSD sono letteralmente la definizione di “binning”, comunque: il 128GB ha die da 1.500 PEC mentre il 256GB da 3.000 PEC (rispettivamente Mediagrade e FortisFlash come valutazione di Micron). Riferisco per il DB di TPU comunque, grazie Pitx.

E credo sia il motivo per cui CDI sballi lo SMART.

Black (Wooden Law)
22-04-2025, 19:16
Ciao a tutti
Qual'è attualmente l'SSD con cache (DRAM o SLC) m.2 PCI-E (non importa la versione) da 500GB o 1TB più economico sul mercato (e magari che non sia di brand semi sconosciuti)?
O se mi dite che per un drive di sistema di un PC semplicemente da ufficio può andare bene anche senza cache, va bene anche quello.
Grazie mille

Il migliore per la tua scelta direi è che il 990 EVO Plus senza ombra di dubbio (l'MP600 Elite costa di più mi pare e non ne vale la pena il prezzo maggiorato). Se ti va, comunque, leggi i post sulla DRAM e sulla cache SLC nella prima pagina per capire che la DRAM non è una cache negli SSD e che tutti gli SSD più recenti usano la cache SLC. ;)

E credo sia il motivo per cui CDI sballi lo SMART.

Nel senso che pensi che S.M.A.R.T. sia buggato perché le NAND flash sono di dubbia qualità? Anche se sono di produzione Micron guarda qui (https://static.mercdn.net/item/detail/orig/photos/m72632724189_9.jpg?1721899348) che "logo" (tra virgolette perché non esiste il logo) e S/N hanno. Direi che forse sono più cinesi che americane...

TonyVe
23-04-2025, 11:54
Fiktow mi pare abbia messo 20 dollari di tasse dal proprio sito.
Prima ti portavi a casa l'FN955 a 85€ circa, da 2TB...ora segna 112 dollari e qualcosa, circa 98€.

Black (Wooden Law)
23-04-2025, 13:06
Fiktow mi pare abbia messo 20 dollari di tasse dal proprio sito.
Prima ti portavi a casa l'FN955 a 85€ circa, da 2TB...ora segna 112 dollari e qualcosa, circa 98€.

Ho notato ma più che “tasse” penso che siano finiti gli sconti e basta…

@Liupen
23-04-2025, 13:36
Nel senso che pensi che S.M.A.R.T. sia buggato perché le NAND flash sono di dubbia qualità? Anche se sono di produzione Micron guarda qui (https://static.mercdn.net/item/detail/orig/photos/m72632724189_9.jpg?1721899348) che "logo" (tra virgolette perché non esiste il logo) e S/N hanno. Direi che forse sono più cinesi che americane...

No, intendo che un controller diverso su NS100 (Maxio e non Marvell) su quel modello, potrebbe essere la causa del problema di conteggio nei dati smart e giustamente fatto notare da Nicodemo Timoteo Taddeo.

Insomma, da https://www.techpowerup.com/ssd-specs/lexar-ns100-512-gb.d599 a https://www.techpowerup.com/ssd-specs/lexar-ns100-1-tb.d2303
ma nel caso dell'ssd di pitx, si ha un ibrido https://www.hwupgrade.it/forum/showpost.php?p=48773146&postcount=23057

mieto
23-04-2025, 20:45
Fiktow mi pare abbia messo 20 dollari di tasse dal proprio sito.
Prima ti portavi a casa l'FN955 a 85€ circa, da 2TB...ora segna 112 dollari e qualcosa, circa 98€.

Vai sul sito Ediloca.

EN870 2Tb (stesso drive del FN955) a 80euro spedito (sconto -10% - logistica Amazon)

Black (Wooden Law)
26-04-2025, 10:26
Quando è uscito questo (https://blocksandfiles.com/2025/04/16/seagate-decarbonizing-data-report/) articolo di Block & Files in cui dice che secondo Seagate gli SSD hanno un impatto ambientale nettamente più alto rispetto agli HDD (160 kgCO₂/TB vs. meno di 1 kgCO₂/TB) sono rimasto abbastanza stranito, anche perché mi vien da pensare che gli HDD, avendo della meccanica al loro interno ed essendo più grandi fisicamente (parlo soprattutto dei 3,5’’), usino dei materiali più inquinanti rispetto agli SSD. Però non ci ho dato troppo peso alla cosa, anche perché non è un argomento che mi interessa più di troppo…

Poi è uscito Embodied Carbon Footprint of 3D NAND Memories (https://hal.science/hal-05015578v2/document) e l’ho letto per curiosità. I punti che trovo interessanti sono questi:
1) il numero di step di produzione per il chip NAND flash dipende sia dal numero di layer che dal numero dei die all’interno del package. La formula per il calcolo del numero dei passaggi necessari per la produzione di un die NAND flash è: NSteps = 179 + 4,3 * NLayers, dove “NLayers” è il numero dei layer del die NAND flash. Per le recenti Micron B68S da 276L il numero di processi è 1.365;
2) la formula per calcolare l’impatto ambientale di un chip è: GChip = NDies * SDies * (γ * δ * NLayers) dove “NDies” è il numero dei die all’interno del package, “SDies” è la dimensione di un die in mm², γ è una costante ed è 4,73 * 10⁻³ e anche δ è una costante con valore di 3,87 * 10⁻⁵. Nel caso di un package B68S da 16DP (cioè da 16 die, il massimo attualmente in commercio) che ha die da 49 mm² il risultato è 0,039 kgCO₂ (per TB assumo);
3) per scoprire la dimensione di un die NAND flash la cosa migliore è guardare le specifiche emesse dal produttore, questo perché usare un rapporto package-die non è affidabile, il die può esser messo in diversi package per diversi usi e anche perché con l’analisi a raggi X è difficile riconoscere i bordi del die NAND flash;
4) lo studio ha prodotto come equazione per l’impatto ambientale di un SSD questa formula: GSSD = CGB / η * d * (δ + γ / NLayers), dove “CGB” è la dimensione dell’SSD in GB, η è la densità della cella di una NAND flash di silicio ed è 2,61 * 10⁻³ e d è il numero di bit per cella (SLC, MLC, TLC, ecc.). Tuttavia, tale formula non rispecchia al 100% la realtà perché nello studio non è stata calcolata l’impronta ambientale del chip controller e del chip DRAM;
5) infine, secondo lo studio, una NAND flash 3D (senza dare specifiche tecniche) emette 22 kgCO₂/TB.

Ho provato a chiedere a ChatGPT di farmi un calcolo utilizzando questa formula e utilizzando il Micron 4600 (B68S) ma è uscito fuori che emette ~6 kgCO₂/TB. Abbastanza irrealistica come cifra visto il numero di Seagate. Poi scopro che l’SSD preso in esame da Seagate è un SSD da datacenter da 30,72TB [1 (https://www.seagate.com/content/dam/seagate/assets/resources/decarbonizing-data-report/decarbonizing-data-report-040325.pdf), pagina 17 punto 6] e forse ci sta come cosa (anche se ripeto, nello studio non è compreso l’impatto ambientale del controller e della DRAM).

pitx
26-04-2025, 12:46
No, intendo che un controller diverso su NS100 (Maxio e non Marvell) su quel modello, potrebbe essere la causa del problema di conteggio nei dati smart e giustamente fatto notare da Nicodemo Timoteo Taddeo.

Insomma, da https://www.techpowerup.com/ssd-specs/lexar-ns100-512-gb.d599 a https://www.techpowerup.com/ssd-specs/lexar-ns100-1-tb.d2303
ma nel caso dell'ssd di pitx, si ha un ibrido https://www.hwupgrade.it/forum/showpost.php?p=48773146&postcount=23057

Va a fortuna...
Hardware Versions:

Marvell 88NV1120 + Micron B16 256 GB 512 GB
MAS1102B + Micron B47R FortisFlash 256 GB
MAS1102B + Micron B47R Mediagrade 128 GB
MAS1102B + YMTC CDT1B X2-9060 256 GB 256 GB 512 GB 1 TB 2 TB

@Liupen
26-04-2025, 17:29
Quando è uscito questo (https://blocksandfiles.com/2025/04/16/seagate-decarbonizing-data-report/) articolo di Block & Files in cui dice che secondo Seagate gli SSD hanno un impatto ambientale nettamente più alto rispetto agli HDD (160 kgCO₂/TB vs. meno di 1 kgCO₂/TB) sono rimasto abbastanza stranito, anche perché mi vien da pensare che gli HDD, avendo della meccanica al loro interno ed essendo più grandi fisicamente (parlo soprattutto dei 3,5’’), usino dei materiali più inquinanti rispetto agli SSD. Però non ci ho dato troppo peso alla cosa, anche perché non è un argomento che mi interessa più di troppo…

Poi è uscito Embodied Carbon Footprint of 3D NAND Memories (https://hal.science/hal-05015578v2/document) e l’ho letto per curiosità. I punti che trovo interessanti sono questi:
1) il numero di step di produzione per il chip NAND flash dipende sia dal numero di layer che dal numero dei die all’interno del package. La formula per il calcolo del numero dei passaggi necessari per la produzione di un die NAND flash è: NSteps = 179 + 4,3 * NLayers, dove “NLayers” è il numero dei layer del die NAND flash. Per le recenti Micron B68S da 276L il numero di processi è 1.365;
2) la formula per calcolare l’impatto ambientale di un chip è: GChip = NDies * SDies * (γ * δ * NLayers) dove “NDies” è il numero dei die all’interno del package, “SDies” è la dimensione di un die in mm², γ è una costante ed è 4,73 * 10⁻³ e anche δ è una costante con valore di 3,87 * 10⁻⁵. Nel caso di un package B68S da 16DP (cioè da 16 die, il massimo attualmente in commercio) che ha die da 49 mm² il risultato è 0,039 kgCO₂ (per TB assumo);
3) per scoprire la dimensione di un die NAND flash la cosa migliore è guardare le specifiche emesse dal produttore, questo perché usare un rapporto package-die non è affidabile, il die può esser messo in diversi package per diversi usi e anche perché con l’analisi a raggi X è difficile riconoscere i bordi del die NAND flash;
4) lo studio ha prodotto come equazione per l’impatto ambientale di un SSD questa formula: GSSD = CGB / η * d * (δ + γ / NLayers), dove “CGB” è la dimensione dell’SSD in GB, η è la densità della cella di una NAND flash di silicio ed è 2,61 * 10⁻³ e d è il numero di bit per cella (SLC, MLC, TLC, ecc.). Tuttavia, tale formula non rispecchia al 100% la realtà perché nello studio non è stata calcolata l’impronta ambientale del chip controller e del chip DRAM;
5) infine, secondo lo studio, una NAND flash 3D (senza dare specifiche tecniche) emette 22 kgCO₂/TB.

Ho provato a chiedere a ChatGPT di farmi un calcolo utilizzando questa formula e utilizzando il Micron 4600 (B68S) ma è uscito fuori che emette ~6 kgCO₂/TB. Abbastanza irrealistica come cifra visto il numero di Seagate. Poi scopro che l’SSD preso in esame da Seagate è un SSD da datacenter da 30,72TB [1 (https://www.seagate.com/content/dam/seagate/assets/resources/decarbonizing-data-report/decarbonizing-data-report-040325.pdf), pagina 17 punto 6] e forse ci sta come cosa (anche se ripeto, nello studio non è compreso l’impatto ambientale del controller e della DRAM).


Argomento interessante.
Speriamo diventi anche preminente o comunque considerato per le tecnologie future..

Va a fortuna...
Hardware Versions:

Marvell 88NV1120 + Micron B16 256 GB 512 GB
MAS1102B + Micron B47R FortisFlash 256 GB
MAS1102B + Micron B47R Mediagrade 128 GB
MAS1102B + YMTC CDT1B X2-9060 256 GB 256 GB 512 GB 1 TB 2 TB


Certamente CDI ha una banca dati grande ma non può star dietro a tutte le versioni di ogni ssd oggetto di variazioni hardware non dichiarate.

Black (Wooden Law)
26-04-2025, 18:41
Argomento interessante.
Speriamo diventi anche preminente o comunque considerato per le tecnologie future..

Sì ma senza esagerare, infatti non ho idea in futuro cosa si possa fare per far scalare i die NAND flash senza aumentare il numero di processi richiesti per la creazione di questi chip. Se attualmente il trend per abbassare i costi e sviluppare le NAND flash è quello di aumentare layer e bit per cella, come possiamo dire che il futuro prospetta bene con questo andamento? Ormai il mondo sta diventando sempre più green (in termini di decisioni politiche, non di qualità dell’ambiente… purtroppo) e si sta cercando di ridurre il life cycle-assessment (LCA) di qualsiasi cosa, qui le NAND flash (e quindi gli SSD) hanno un LCA nettamente superiori degli HDD. O si cambia tecnologia (ma ci sono altri millemila problemi con gli altri tipi di memoria non volatile) oppure torniamo agli HDD, ma la vedo impossible come cosa.

Confidiamo nella ricerca e basta, e speriamo che Seagate non abbia fatto notare un problema gigante da sempre nascosto.

frafelix
28-04-2025, 13:33
C'è da dire che tornando alla società ASML (di qualche pagina fa) che produce i macchinari per fare i chip, nand comprese, più extreme ultraviolet usi meno passaggi devi fare per costruire lo stesso chip.
Da qui sicuramente avrai una resa maggiore visto che riduci i rischi di rovinare i wafer, ma non so se i costi energetici (quindi sia in dollari che in emissioni) si riducano o meno visto che i macchinari richiedono più potenza per il laser.


Secondo me se fosse davvero come dice Seagate, o si cambia tutto il sistema o non se ne esce. Per esempio nelle schede video stiamo andando nella direzione che più della potenza bruta puntiamo sull'intelligenza artificiale (da anni non da adesso che fa figo) semplicemente perché per gestire tutti gli effetti grafici in ray tracing non c'è abbastanza potenza bruta per farlo, quindi hanno cambiato approccio. Dovrebbero fare così anche qui se possibile

@Liupen
29-04-2025, 16:19
C'è da dire che tornando alla società ASML (di qualche pagina fa) che produce i macchinari per fare i chip, nand comprese, più extreme ultraviolet usi meno passaggi devi fare per costruire lo stesso chip.
Da qui sicuramente avrai una resa maggiore visto che riduci i rischi di rovinare i wafer, ma non so se i costi energetici (quindi sia in dollari che in emissioni) si riducano o meno visto che i macchinari richiedono più potenza per il laser.

"ASML gode di una posizione di (quasi) monopolio globale nella fornitura di apparecchiature di litografia ultravioletta estrema (EUV) necessarie per la produzione di chip più avanzati, dagli acceleratori di intelligenza artificiale (IA) ai chip degli smartphone".

Questo excursus è molto molto interessante.. anche solo per avere un idea di come vengono realizzati i chip e le nand flash
https://www.elettronicaemercati.it/la-tecnologia-euv-per-la-produzione-di-semiconduttori-avanzati/


Secondo me se fosse davvero come dice Seagate, o si cambia tutto il sistema o non se ne esce. Per esempio nelle schede video stiamo andando nella direzione che più della potenza bruta puntiamo sull'intelligenza artificiale (da anni non da adesso che fa figo) semplicemente perché per gestire tutti gli effetti grafici in ray tracing non c'è abbastanza potenza bruta per farlo, quindi hanno cambiato approccio. Dovrebbero fare così anche qui se possibile

Bello spunto, diciamo che il parallelo è "evocativo".
Seagate pensa al prodotto di memorizzazione ibridato con la AI, ma altre aziende pensano proprio allo sviluppo della componente AI (SK Hynix).

Come la scheda video trae vantaggi da un processo diverso di elaborazione, sono in atto per lo storage un near-data processing integrato, cioè

"l’idea di spostare una parte dell’elaborazione dei dati «vicino» al supporto di memoria in cui risiedono, anziché trasferirli su bus a lunga percorrenza (es. PCIe → CPU → RAM → CPU → storage)"


Quindi l'AI tenderà a creare Controller multiprocessore più potenti che integrano delle funzioni superiori ma mantenendo le compatibilità tecnologiche attuali, quindi anche la tecnologia delle Nand Flash.

E' probabile che sia lo step successivo a questo in attesa poi di introdurre nuove tecnologie (es. la Xpoint 2.0 o le celle quantistiche).

NB. si, sono tecnologie di fantasia ;)

Black (Wooden Law)
29-04-2025, 19:51
Quindi l'AI tenderà a creare Controller multiprocessore più potenti che integrano delle funzioni superiori ma mantenendo le compatibilità tecnologiche attuali, quindi anche la tecnologia delle Nand Flash.

Dato questo ragionamento penso che a 'sto punto sia utile individuare chi sia il colpevole delle tante emissioni negli SSD (a patto che i calcoli di Seagate siano giusti) e cercare di trovare soluzioni ad esso inerente. Se è il controller giù di NMP, per esempio (anche se ho letto che è per HBM e magari il discorso è diverso per le NAND flash), o magari varie tecnologie di data placement (https://semiconductor.samsung.com/news-events/tech-blog/a-brief-history-of-data-placement-technologies/) (che conosciamo molto bene), ma se il colpevole è il tipo di memoria lì c'è poco da fare IMHO, ridurre le operazioni software non porta ad un abbattimento delle emissioni dovute dai processi di produzione, servirebbe rivedere lo scaling per abbassare le fasi in produzione (penso eh, purtroppo non sono né un ingegnere né un ricercatore). O comunque se non si rivedono passaggi all'interno della produzione di NAND flash si attendono nuovi tipi di memoria come detto da te Liupen, il problema è che la strada è ancora lontana nonostante escano "prototipi a gogo" (vedere UltraRAM (https://en.wikipedia.org/wiki/UltraRAM) e Phase-change Oxide (POX) (https://www.tomshw.it/hardware/la-memoria-flash-piu-veloce-al-mondo-scrive-in-04-nanosecondi-2025-04-18)).

Black (Wooden Law)
29-04-2025, 23:08
Mi sembra incredibile come nel 2025 ancora non si sia capita l'inesistenza del gaming negli SSD, nel senso che non esistono SSD fatti per il gaming: https://www.pcgamesn.com/wd/black-sn8100-gaming-ssd-rumor. Però vabbè, aldilà di questo, WD SN8100, SM2508 con (sicuramente) NAND flash Kioxia BiCS8.

piwi
29-04-2025, 23:35
Se ha le lucine è gaming ;)

frafelix
30-04-2025, 09:19
Mi sembra incredibile come nel 2025 ancora non si sia capita l'inesistenza del gaming negli SSD, nel senso che non esistono SSD fatti per il gaming: https://www.pcgamesn.com/wd/black-sn8100-gaming-ssd-rumor. Però vabbè, aldilà di questo, WD SN8100, SM2508 con (sicuramente) NAND flash Kioxia BiCS8.

A parte che come dici non serve, l'unico vantaggio di ssd veloci nel gaming potrà essere direct storage una volta che le software house lo implementeranno nei giochi...

Se ha le lucine è gaming ;)
Questo sempre, ormai è una certezza!

giovanni69
30-04-2025, 09:28
https://i.postimg.cc/8cQFkKvw/lucine.jpg (https://postimages.org/)

:D

Ma non ce l'ho..! :cry: ;)

TonyVe
30-04-2025, 16:18
Vai sul sito Ediloca.
EN870 2Tb (stesso drive del FN955) a 80euro spedito (sconto -10% - logistica Amazon)


Si sono adeguati. :D
97€.

mieto
30-04-2025, 18:36
Si sono adeguati. :D
97€.

In questo momento se metto a carrello il 2Tb EN870 mi da 88.95 euro -10% di sconto = 80.05 euro spedito :O

TonyVe
30-04-2025, 19:25
@mieto

https://i.imgur.com/yOKsF7V.jpeg


Se me lo sai spiegare ti ringrazio! :D
Sia da loggato sia da non loggato.
Spedizione non in posto particolare.

Il puntino di domanda dice: The final tax and total will be confirmed by email or text after you place your order

mieto
30-04-2025, 20:38
@mieto

Se me lo sai spiegare ti ringrazio! :D
Sia da loggato sia da non loggato.
Spedizione non in posto particolare.

Il puntino di domanda dice: The final tax and total will be confirmed by email or text after you place your order

'azzarola adesso esce anche a me la voce "Estimated taxes" :doh:

Non capisco perchè se la destinazione è ad es: in Austria le tasse vanno a zero, se invece è Germania o Italia compaiono le tasse... :mbe:

Peccato...

Black (Wooden Law)
02-05-2025, 15:01
Recensione cinese del Kingston Fury Renegade G5: https://youtu.be/6yjRG_1jzx8?si=v-MQuwkungKov_ta.

Confermato l’SM2508 con NAND flash Kioxia BiCS8 (non capisco perché hanno implementato queste NAND flash che sono “vecchie” e peggiori rispetto alle B68S o alle YMTC 267L). Al minuto 1:13 le performance su CDM, dove sono peggiori rispetto agli SM2508 con B58R come il BIWIN X570 Pro, peggiori rispetto agli SM2508 con YMTC 267L e sul livello dei MAP1806 con EET1A e del 9100 PRO. In cache SLC dimostra essere un full-drive SLC con ~645GB di cache SLC, una velocità direct-to-TLC di 2.500 MB/s e uno stato di folding dovuto dall’enorme cache SLC di 1.500 MB/s.

Le performance sono buone (non ottime, ottime lo sono degli SSD che hanno NAND flash più recenti e migliori) ma rimango molto deluso sulla scelta delle NAND flash. Per essere il primo drive Gen5 con BiCS8 che vedo mi aspettavo molto di meglio.

Per ora, tra tutti i Gen5 che abbiamo visto, 4600 > Ti9000 Pro > P51 > Fury Renegade G5 > 9100 PRO > C5000. L’unico motivo per il quale metto il C5000 sotto al 9100 PRO è perché è DRAM-less e ha performance randomiche peggiori (ma forse non dovute per la mancanza della DRAM ma per il firmware mal ottimizzato del controller), d’altronde lo preferisco personalmente. Probabile che in futuro, infatti, ammettendo aggiornamenti del firmware di miglioramento delle performance, lo consiglierò rispetto al 9100 PRO.

Una cosa che trovo davvero interessante è il riferimento dell’articolo scritto sulla cache SLC (https://freewechat.com/a/MzkzMjYyNDU4Mg==/2247484816/1) al minuto 4:07. Nell’articolo i punti secondo me più importanti sono:
1) WD dice che la cache SLC (da loro chiamata “nCache”) all’inizio era fatta per ospitare soltanto la mappa L2P delle NAND flash e le scritture di piccole dimensioni (meno di 4kB), poi con nCache 2.0 la cache SLC ha incominciato ad ospitare qualsiasi scrittura di qualsiasi dimensione e soprattutto è aumentata di capacità, passando da 5GB a 120GB. Qui è stato introdotto anche il folding. Altro punto interessante è che con nCache 2.0 qualsiasi scrittura veniva mandata in cache SLC comportando a del folding obbligatorio dopo l’esaurimento del buffer SLC e a poche scritture sulle NAND flash TLC. Poi, con le NAND flash TLC 3D che hanno visto miglioramenti sia in performance che durata, han deciso di introdurre (con nCache 3.0) le scritture “direct-to-TLC” in modo tale da indirizzare le scritture su NAND flash TLC dopo l’esaurimento del buffer SLC; così facendo non si fa per forza del folding;
2) una cache SLC “virtuale” fatta in questa maniera è sicuramente migliore rispetto ad una cache SLC “fisica”, questo perché quella fisica richiederebbe un’espansione del numero di blocchi fisici e quindi una struttura FTL “peggiore”;
3) HOMOLAB ci conferma che finché le scritture vengono effettuate in cache SLC la durata aumenta.

Black (Wooden Law)
05-05-2025, 18:58
Segnalo Seagate FireCuda 530R da 1TB a 87 euro (https://www.amazon.it/dp/B0CWHF1QYB?ref=cm_sw_r_apin_dp_6X0ETQ172F55CKDCYFT5&ref_=cm_sw_r_apin_dp_6X0ETQ172F55CKDCYFT5&social_share=cm_sw_r_apin_dp_6X0ETQ172F55CKDCYFT5&previewDoh=1&tag=sdhardware-21&th=1). La componentistica è Phison E18 con NAND flash Kioxia BiCS6 (162L), è sicuramente una versione migliore del FireCuda 530 e di tanti altri PCIe 4.0 come l'SN850X, Fury Renegade, ecc.

@Liupen
06-05-2025, 09:27
In cache SLC dimostra essere un full-drive SLC con ~645GB di cache SLC, una velocità direct-to-TLC di 2.500 MB/s e uno stato di folding dovuto dall’enorme cache SLC di 1.500 MB/s.

Mumble...mumble....

E' un po strana la situazione: di solito prima il controller utilizza la scrittura diretta (nel test l'ssd è VUOTO) e poi, diciamo, "va in crisi" gestendo il folding (writeback).
In stato di folding si osservano quelli che sono i pregi e difetti del firmware nello scrivere assiduamente (condizione limite quanto non troppo lontana dalla realtà se si ha a che fare con un ssd normalmente usato e "normalmente" pienotto).

Tornando però al Renegade G5 in questa versione da 2TB, dopo aver scritto oltre 600 GB in cache emulata SLC, invece di scrivere al termine della cache sulle celle (TLC nello specifico), cerca di ripristinare la cache, quindi writeback SLC---> TLC + TLC direct-to. Molto stupido.

Sono andato a prendere la recensione di THW del Micron 4600 2TB. per capire un comportamento base del SM2508 (controller).
La cache SLC risulta della metà e l'ssd procede giustamente in direct-to write su celle TLC (in questo caso le Micron) a poco meno 4 GB/s (che è buono).

Se come scelta è voluta è quantomeno interessante... al netto del firmware che ha comunque bisogno di un aggiustatina perchè si parla di un problema di recupero.

Cerchiamo di capire, Black, le conseguenze di questo approccio.

Immaginando un ssd nvme Renegade G5 pieno a oltre il 70% ed usato continuamente da un paio d'anni con dati statici/dinamici che hanno previsto cancellazioni e riscritture, questa programmazione, porta effettivamente qualche vantaggio per un utente domestico?




Una cosa che trovo davvero interessante è il riferimento dell’articolo scritto sulla cache SLC (https://freewechat.com/a/MzkzMjYyNDU4Mg==/2247484816/1) al minuto 4:07. Nell’articolo i punti secondo me più importanti sono:
1) WD dice che la cache SLC (da loro chiamata “nCache”) all’inizio era fatta per ospitare soltanto la mappa L2P delle NAND flash e le scritture di piccole dimensioni (meno di 4kB), poi con nCache 2.0 la cache SLC ha incominciato ad ospitare qualsiasi scrittura di qualsiasi dimensione e soprattutto è aumentata di capacità, passando da 5GB a 120GB. Qui è stato introdotto anche il folding. Altro punto interessante è che con nCache 2.0 qualsiasi scrittura veniva mandata in cache SLC comportando a del folding obbligatorio dopo l’esaurimento del buffer SLC e a poche scritture sulle NAND flash TLC. Poi, con le NAND flash TLC 3D che hanno visto miglioramenti sia in performance che durata, han deciso di introdurre (con nCache 3.0) le scritture “direct-to-TLC” in modo tale da indirizzare le scritture su NAND flash TLC dopo l’esaurimento del buffer SLC; così facendo non si fa per forza del folding;
2) una cache SLC “virtuale” fatta in questa maniera è sicuramente migliore rispetto ad una cache SLC “fisica”, questo perché quella fisica richiederebbe un’espansione del numero di blocchi fisici e quindi una struttura FTL “peggiore”;
3) HOMOLAB ci conferma che finché le scritture vengono effettuate in cache SLC la durata aumenta.

Cosa hai scovato di bello? ;)
leggo... caspita che tono... davvero si da dell'imbecille a qualcuno?
I Like It!
Ahahaha!

@Liupen
06-05-2025, 15:39
Gli ssd aziendali utilizzano la cache emulata, ci mancherebbe!
La nuova generazione di ssd aziendali li rende un'alternativa economicamente vantaggiosa alla soluzione enterprise classica.
Anzi siamo ora al punto che celle TLC vengono emulate SLC totalmente per permettere all'ssd U2 Pcie di avere una reattività e velocità migliore ad un costo decisamente più basso.

Già come affermazioni iniziali, non so se il cogl***e può essere il tizio che scrive e non quello a cui si riferisce...


Punto 1) Black
Io c'ero.. e qualcun altro quì c'era quando è nata negli ssd la nCache di Sandisk.
Poi partì anche il turbowrite di Samsung ma Sandisk fu la prima, già quando cercava buone prestazioni con gli ssd sata MLC.

Ah, tra l'altro si tratta di Sansisk... S A N D I S K non certo WD come scrive il tipo.
Sandisk quella originale, vera, partner di Toshiba e nel gota degli ssd con poche altre: OCZ, Samsung, Micron/Crucial. Stiamo parlando del 2011-2012.

Non mi risulta che la prima forma di nCache fosse stata creata per la mappatura. Che cosa stupida... gli ssd MLC avevano un bella DRAM che serviva solo a quello, e i TLC non sono diversi.
Mi spiega il tipo perchè comprimere in SLC una mappatura che stà bella bella su DRAM che è decine e decine di volte veloce e con meno latenza?
La versione perfezionata nCache 2.0 si trova schematizzata ancora in alcuni siti
https://www.legitreviews.com/sandisk-ultra-ii-240gb-ssd-review_150395
https://www.computerbase.de/artikel/storage/sandisk-ultra-ii-2-ssd-test.53025/seite-2
https://www.thessdreview.com/our-reviews/sandisk-ultra-ii-ssd-review-240gb/

E si, uno dei motivi per la creazione della cache emulata (nonostante il pensiero dell'autore) e che questa permette di mantenere le prestazioni degli ssd TLC (sata ovviamente... gli nvme non esistevano proprio) come quelli MLC (che saturavano la banda del sata stesso... oltre sarebbe stato assurdo fare).

Mo parto con lo spiegone...

Se si vuole proprio proprio fare una storia chiara sulla nCache, che NON E' proprio uguale alla pSLC a cui siamo ora abituati, si deve partire dal perchè viene "inventata".

Nascono gli ssd (sata) TLC e si nota che la scrittura ha prestazioni inferiori agli MLC.
Quindi non sarebbero ssd molto apprezzati, oltre al fatto che non è che costassero poi tanto meno degli ormai affermati MLC. Bisognava trovare il modo di "accelerare".
La causa della lentezza delle scritture su TLC è dovuta alla velocità minore di programmazione delle TLC, ma c'è un grosso, grosso problema che occorre affrontare: la maggiore amplificazione in scrittura che è concausa della durata inferiore dei dispositivi TLC.

L'idea della cache emulata già c'era ed è ulteriormente sviluppata. E' fantastica: Avere a bordo un po' di SLC per memorizzare i dati nella cache prima di scaricarli nella TLC riduce notevolmente l'amplificazione in scrittura e quindi la durata del disco risulta migliorata.

Ora il come: il processo nCache garantisce che tutti i dati vengano inizialmente scritti nei blocchi SLC prima di essere trasferiti alla TLC. Sandisk parla di "On Chip Copy" perchè si tratta di una porzione di celle/pagine/blocchi gestite dal die che vengono utilizzate in modo speciale.
Il "folded" cioè la piega, è la seconda fase del meccanismo di nCache (termine poi esteso a tutti gli effetti dell pSLC), cioè la copia su chip, da SLC a TLC. I blocchi TLC vengono quindi scritti in sequenza per ottimizzare l'amplificazione in scrittura. L'operazione di copia viene eseguita interamente all'interno della NAND, senza la necessità di utilizzare il controller o la DRAM.

Ricapitolando:
nCache è nato per le performance
nCache ha l'effetto di mitigare la WA
nCache utilizza blocchi specificatamente emultati e la gestione è a livello di die (quindi di chip)
nCache ha lo stato di folding come seconda fase del processo di cache emultata.

Vediamoquindi quando dici: "con nCache 2.0 qualsiasi scrittura veniva mandata in cache SLC comportando a del folding obbligatorio dopo l’esaurimento del buffer SLC e a poche scritture sulle NAND flash TLC. Poi, con le NAND flash TLC 3D che hanno visto miglioramenti sia in performance che durata, han deciso di introdurre (con nCache 3.0) le scritture “direct-to-TLC” in modo tale da indirizzare le scritture su NAND flash TLC dopo l’esaurimento del buffer SLC; così facendo non si fa per forza del folding".

La prima frase si matcha con il ricapitoliamo... anche se il folding, meglio dirlo, risulta sempre necessario nella nCache, perchè è la fase due del processo: Scrivo SLC --> copio in TLC

Ora stò leggendo quanto scritto dal tipo: "Oltre alle prestazioni di scrittura a 128K, è anche estremamente ovvio ottimizzare la struttura FTL: il semplice mantenimento della mappatura della cache SLC è molto più semplice dell'espansione completa del blocco fisico. Per quanto riguarda le prestazioni utente, la cache SLC può spesso ottenere il mapping a livello di blocco o addirittura di pagina senza la necessità di espandere nuovamente la tabella, e il miglioramento delle prestazioni che ne risulta è molto evidente: questo vale sia per le tecnologie dramless che per quelle drambased. A causa della mancanza di strategie di risparmio energetico e di protezione contro lo spegnimento, anche il modello di punta configurato a 1:1000 non riesce a ottenere lo stesso effetto di quello aziendale."

Penso che il tipo si sia pippato qualche cosa. Perchè farla così complicata?
Mappatura.. espansione.. ecc ecc.

Ma è semplice!
https://pics.computerbase.de/6/9/7/7/8/10-1080.824971055.jpg
nCache funziona a livello di die... di chip.
Tutto ciò che entra nell'ssd nella maniera più grezza possibile, viene prima scritto in SLC e poi ricopiato sullo stesso die nella controparte di celle TLC.
In automatico, non serve il controller (occhio a questo che è il motivo per cui nCache ≠ pSLC).
E la mappatura - su DRAM - che fà?
Viene aggiornata di conseguenza.
Fold-set, il controller rimappa, raggruppando i dati memorizzati in 3 blocchi SLC “da svuotare” e li associa insieme in un unico blocco TLC già cancellato. Il controller invia poi il comando Erase sui 3 blocchi SLC originari, che tornano liberi per future scritture rapide.

Semplice, lineare, vincente...


Quando leggo dopo: "Per questo motivo, la cache SLC non è ottimizzata per 128K, come molti autodidatti incompetenti credono. ", mi viene solo da sorridere, perchè l'autore confondo la nCache 2.0 con la "nostra" pSLC.

Ripeto, nCache è "ignorante". Anche se entrasse un treno nell'ssd (tanto per dire un dato sequenziale da 1MiB, questo viene preso, scritto in SLC. Dopodichè... On‑Chip Copy - È una logica integrata direttamente all’interno del die NAND che permette di:
A) Leggere una word‑line (una pagina) e tenerla in latch interni
B) Riprogrommarla in un’altra pagina di destinazione sulla stessa die
il tutto senza passare dal bus verso il controller SSD né dalla DRAM del controller.
[Cit. Sandisk]


Ora, dopo aver smesso di ridere in faccia al tipo che dà degli incompetenti agli altri, ciccando il parallelo tra due cose diverse che hanno in comune la parola "cache", tornando alla sua dissertazione... intanto posto questo e poi domani continuo a leggermi da:

PARTE II Algoritmi SLC

2.1 Nella cache

Black (Wooden Law)
06-05-2025, 23:36
Mumble...mumble....

Cerchiamo di capire, Black, le conseguenze di questo approccio.

Immaginando un ssd nvme Renegade G5 pieno a oltre il 70% ed usato continuamente da un paio d'anni con dati statici/dinamici che hanno previsto cancellazioni e riscritture, questa programmazione, porta effettivamente qualche vantaggio per un utente domestico?

Questo approccio di cui parli l'ho notato già tempo fa con le sue recensioni sul PM9E1 (https://imgur.com/a/aAgDbCC) (OEM del 9100 PRO), PCB01 (https://imgur.com/a/PUOhKxO) (OEM del P51) e del 990 EVO Plus (https://imgur.com/a/6YWbN1L), semplicemente l'ho sempre ignorato perché non combacia con quello mostrato nelle recensioni degli altri recensori. Nel senso che Tom's Hardware non mostra alcun folding per il 9100 PRO e per il 990 EVO Plus, se HOMOLAB lo fa mi viene da pensare che abbia una configurazione di test molto diversa rispetto ai recensori a cui noi siamo abituati a consultare oppure che lui sbaglia qualcosa con i test stessi. In ogni caso, rispondendo a "porta effettivamente qualche vantaggio per un utente domestico?", io penso che fare del folding prima delle scritture direct-to-TLC porti a un minor WAF. Due motivi per questo:
1) il folding in sé è la compressione di 3 blocchi SLC in 1 TLC e questa è un'operazione sequenziale [1] (https://patentimages.storage.googleapis.com/d9/30/46/3ba3f5b8cdbcc5/US9858009.pdf). Tante scritture di questo tipo (ossia sequenziali) riempiono sequenzialmente un blocco e un blocco sequenziale non necessita di tutte le operazioni di lettura, cancellatura, modifica e scritture che fa il GC con un blocco scritto randomicamente [2] (https://en.wikipedia.org/wiki/Write_amplification#Sequential_writes), quindi le scritture e i blocchi sequenziali hanno un WAF più basso rispetto a quelle/i randomiche;
2) se ci pensi, per arrivare a fare delle scritture direct-to-TLC dopo il folding devi consumare in primo step tutta la cache SLC che tipicamente è di 200+GB (è un numero generale, poi ci sono SSD e SSD) e poi devi superare tutto lo stadio di folding che non so di quanti GB è fatto (sicuro non di pochi). Penso che l'utente debba trasferire una quantità di dati ingente per arrivare alle scritture direct-to-TLC dopo tutto questo e visto il vantaggio del WAF più basso tanto vale far consumare il meno possibile le celle NAND flash.

Tu dopo questo ragionamento potrai dirmi "sì ma così hai performance più basse", vero e non ti do contro, non c'è alcuna positività per la velocità dell'SSD, ma non mi vengono in mente altri motivi per i quali fare folding prima di scritture in direct-to-TLC.

Ora, dopo aver smesso di ridere in faccia al tipo che dà degli incompetenti agli altri, ciccando il parallelo tra due cose diverse che hanno in comune la parola "cache", tornando alla sua dissertazione...

Beh non ho molto da dire Liupen, alla fine hai spiegato in modo molto più esteso e dettagliato la parte sopra del mio messaggio (che l'ho scritta prima di leggere il tuo ultimo commento) e ovviamente son d'accordo su tutto. Folding alla fine è una scrittura on-die e on-chip-copy, quindi i blocchi SLC sono catalogati in un foldset, poi questi blocchi SLC vengono compressi in TLC nel foldset dei blocchi TLC.

Son d'accordo anche su quanto hai detto a riguardo di "Mappatura.. espansione.. ecc ecc.". Quando lessi la prima volta quel pezzo di testo dissi "deve aver sbagliato qualcosa la traduzione, non ha senso sta roba. Fammi provare a tradurre in italiano..."... e indovina? Anche lì non aveva senso, quindi ho pensato "o fa schifo la traduzione dal cinese oppure lui ha messo in mezzo cose che non c'entrano nulla, o che perlomeno non sono documentate da nessuno", quindi ho provato a prendere il buono e buttarlo giù come punto interessante (secondo punto del post originario).

Unica cosa, questo:
Non mi risulta che la prima forma di nCache fosse stata creata per la mappatura.
Proviene da qui (https://www.anandtech.com/show/12543/the-western-digital-wd-black-3d-nand-ssd-review/2), dalla prima recensione dell'SN750 di AnandTech. Di AnandTech mi fidavo molto, quindi non son sicuro che sia una cavolata quello scritto da loro/HOMOLAB, magari la fonte è vecchia e ora le cose son cambiate, non so.

pitx
06-05-2025, 23:47
Black, ma allo stato attuale S-Ata con controller Marvell, che cosa c'è?

E per un 512GB o 1TB sempre S-Ata, che consigliate?

Black (Wooden Law)
06-05-2025, 23:53
Black, ma allo stato attuale S-Ata con controller Marvell, che cosa c'è?

E per un 512GB o 1TB sempre S-Ata, che consigliate?

Ti interessa un SSD con controller Marvell per qualche motivo specifico? Con controller Marvell mi viene in mente soltanto l'NS100 (che comunque soffre di bait-and-switch ed è stato avvistato con controller MAS1102B) che usa l'88NV1120 (fascia bassa), altrimenti nessuno se non i vecchi SATA WD: WD Blue 3D, SA500, ecc. Loro usano l'antichissimo (ma buono) 88SS1074 che comunque è sempre stato un buon rivale dell'eccellente SM2258 dell'MX500.

Generalizzando su modelli che consiglio rimangono gli stessi della prima pagina: MX500, 870 EVO e A55. Magari anche il BX500 ma con quest'ultimo corri maggiormente il rischio che ti capiti QLC secondo me.

pitx
07-05-2025, 00:25
un buon rivale dell'eccellente SM2258 dell'MX500.

Generalizzando su modelli che consiglio rimangono gli stessi della prima pagina: MX500, 870 EVO e A55. Magari anche il BX500 ma con quest'ultimo corri maggiormente il rischio che ti capiti QLC secondo me.

Più per sfizio il marvell... doveva averlo il Sandisk SSD PLUS(con SN2256S), doveva averlo il Lexar NS100 (ho 2x 128GB, 2x 256GB e tutti col Maxio)
Un SM2258 ce l'ho sul Drevo X1 Pro da 64GB :D

A55?

Black (Wooden Law)
07-05-2025, 01:32
A55?

Ha più versioni di controller e NAND flash, io come controller ho visto S11, SM2259XT e MAS1102 mentre come NAND flash di tutto di più, sia TLC che QLC e dalle 64L alle 232L.

@Liupen
07-05-2025, 15:58
Questo approccio di cui parli l'ho notato già tempo fa con le sue recensioni sul PM9E1 (https://imgur.com/a/aAgDbCC) (OEM del 9100 PRO), PCB01 (https://imgur.com/a/PUOhKxO) (OEM del P51) e del 990 EVO Plus (https://imgur.com/a/6YWbN1L), semplicemente l'ho sempre ignorato perché non combacia con quello mostrato nelle recensioni degli altri recensori. Nel senso che Tom's Hardware non mostra alcun folding per il 9100 PRO e per il 990 EVO Plus, se HOMOLAB lo fa mi viene da pensare che abbia una configurazione di test molto diversa rispetto ai recensori a cui noi siamo abituati a consultare oppure che lui sbaglia qualcosa con i test stessi. In ogni caso, rispondendo a "porta effettivamente qualche vantaggio per un utente domestico?", io penso che fare del folding prima delle scritture direct-to-TLC porti a un minor WAF. Due motivi per questo:
1) il folding in sé è la compressione di 3 blocchi SLC in 1 TLC e questa è un'operazione sequenziale [1] (https://patentimages.storage.googleapis.com/d9/30/46/3ba3f5b8cdbcc5/US9858009.pdf). Tante scritture di questo tipo (ossia sequenziali) riempiono sequenzialmente un blocco e un blocco sequenziale non necessita di tutte le operazioni di lettura, cancellatura, modifica e scritture che fa il GC con un blocco scritto randomicamente [2] (https://en.wikipedia.org/wiki/Write_amplification#Sequential_writes), quindi le scritture e i blocchi sequenziali hanno un WAF più basso rispetto a quelle/i randomiche;
2) se ci pensi, per arrivare a fare delle scritture direct-to-TLC dopo il folding devi consumare in primo step tutta la cache SLC che tipicamente è di 200+GB (è un numero generale, poi ci sono SSD e SSD) e poi devi superare tutto lo stadio di folding che non so di quanti GB è fatto (sicuro non di pochi). Penso che l'utente debba trasferire una quantità di dati ingente per arrivare alle scritture direct-to-TLC dopo tutto questo e visto il vantaggio del WAF più basso tanto vale far consumare il meno possibile le celle NAND flash.

Tu dopo questo ragionamento potrai dirmi "sì ma così hai performance più basse", vero e non ti do contro, non c'è alcuna positività per la velocità dell'SSD, ma non mi vengono in mente altri motivi per i quali fare folding prima di scritture in direct-to-TLC.

Ah ecco, è una cosa legata al suo test.. si, magari le impostazioni fio usate possono determinare comportamenti diversi. Aspetteremo dunque l'analisi di THW.
Se riesci linka la recensione di questo recensore cinese del 9100 PRO così mi faccio un idea delle differenze dello stato stazionario trovato rispetto a https://www.tomshardware.com/pc-components/ssds/samsung-9100-pro-ssd-review/2

L'analisi che hai fatto mi piace, la condivido (il punto 2, perchè l'1 è comunque comune ad entrambe le modalità di gestione).
Penso che sia un ssd che giochi molto sulla grandezza della cache pSLC...anzi che dia tutto per la cache pSLC, dopodichè il crollo. Dai, vediamo che diranno le future recensioni.



Beh non ho molto da dire Liupen, alla fine hai spiegato in modo molto più esteso e dettagliato la parte sopra del mio messaggio (che l'ho scritta prima di leggere il tuo ultimo commento) e ovviamente son d'accordo su tutto. Folding alla fine è una scrittura on-die e on-chip-copy, quindi i blocchi SLC sono catalogati in un foldset, poi questi blocchi SLC vengono compressi in TLC nel foldset dei blocchi TLC.

Son d'accordo anche su quanto hai detto a riguardo di "Mappatura.. espansione.. ecc ecc.". Quando lessi la prima volta quel pezzo di testo dissi "deve aver sbagliato qualcosa la traduzione, non ha senso sta roba. Fammi provare a tradurre in italiano..."... e indovina? Anche lì non aveva senso, quindi ho pensato "o fa schifo la traduzione dal cinese oppure lui ha messo in mezzo cose che non c'entrano nulla, o che perlomeno non sono documentate da nessuno", quindi ho provato a prendere il buono e buttarlo giù come punto interessante (secondo punto del post originario).

Unica cosa, questo:

Proviene da qui (https://www.anandtech.com/show/12543/the-western-digital-wd-black-3d-nand-ssd-review/2), dalla prima recensione dell'SN750 di AnandTech. Di AnandTech mi fidavo molto, quindi non son sicuro che sia una cavolata quello scritto da loro/HOMOLAB, magari la fonte è vecchia e ora le cose son cambiate, non so.

Come la nCache è simile ma non la stessa cosa della pSLC, anche il folding ha assunto poi connotazioni diverse.

Inizialmente era la riscrittura dalla porzione di celle emulate SLC a TLC, stop, non avveniva direct-to write, ora è un insieme di cose, ecco perchè spesso si definisce: "stato di folding".

Il controller dell'ssd (nvme) attuale, in scrittura assidua e spazio libero ristretto (praticamente la normalità se si usa un ssd con qualche scrittura pesante), finita la cache pSLC disponibile, inizia a fare diverse cose in contemporanea:
- scrive in direct-to per continuare la scrittura ordinata dall'host
- sposta le pagine per liberare blocchi e predisporsi alla scrittura (GC)
- copia (sequenzialmente come scrivi su) il contenuto delle celle SLC in formato TLC (su ovviamente nuove celle che sono ovviamente ancora diverse da quelle del punto precedente)
- erase sulle celle emulate SLC
- creazione di nuovo spazio pSLC

Questo è lo stato di folding, che coincide con il massimo impegno del controller e dunque le prestazioni più basse dell'ssd in scrittura.

In seguito, continuando a scrivere in direct-to, con nuova cache pSLC libera, si vede l'impennata di prestazioni, fino a riempimento cache e così via... in un loop gestito chi meglio, chi peggio dal controller.
Questa fase è quasi sempre definita come "stato stazionario" (steady‑state) perchè è l'equilibrio definito dalla programmazione del controller, in cui c'è sia scrittura diretta, che scrittura su cache pSLC in un continuo riempi/copia/svuota.

Riguardo la mappatura in nCache, hai ragione, ho letto Anandtech... riporta proprio quello, parola per parola come hai scritto.

Dovendo capire, quindi, sono andato a prendere una scheda di un vecchio ssd Sandisk 2010 SSD Sandisk P4 sata II (300) https://datasheet.octopart.com/SDSA4AH-032G-SanDisk-datasheet-10977758.pdf in cui è implementata la nCache originale.

La terza generazione di SSD modulari, l'SSD P4, supporta una funzionalità unica per migliorare le prestazioni di scrittura casuale e garantire un'esperienza utente estremamente positiva.
Gli studi dimostrano che i sistemi operativi moderni accedono principalmente al dispositivo di archiviazione utilizzando piccoli blocchi di accesso, la maggior parte dei quali da 4 KB.
I piccoli blocchi di accesso logico sono in conflitto con la struttura a blocchi fisici (>1 MB) della tecnologia di memoria flash di nuova generazione. Pertanto, per colmare questa differenza, l'SSD P4 utilizza una cache di scrittura Flash SLC non volatile, nCache™. nCache™ viene utilizzata per accumulare queste piccole scritture (chiamate segmenti) ad alta velocità e quindi scaricarle e consolidarle in background in una sezione MLC più grande della matrice di memoria Flash NAND durante i periodi di inattività.

La dimensione della cache dell'SSD P4 è di oltre 500 MB, un ordine di grandezza superiore rispetto ad altre soluzioni concorrenti che utilizzano cache basate su DRAM.

La dimensione della cache varia in base alla capacità. Per il prodotto da 32 GB, la dimensione della cache è di oltre 500 MB.

Grazie alle sue grandi dimensioni, per la maggior parte dell'attività giornaliera degli utenti, nCache non va mai in overflow e gli utenti finali sperimentano elevate prestazioni SLC burst piuttosto che prestazioni sostenute. Una volta che nCache si riempie, le prestazioni dell'SSD P4 scendono fino a raggiungere la condizione di stato stazionario.
Inoltre, nCache è una cache non volatile e quindi non è esposta a perdite di dati.

Per evitare qualsiasi perdita di dati durante la rimozione dell'alimentazione (con Host Write Cache disabilitata), il tempo necessario alla tensione di ingresso per scendere dal valore nominale a 2 V deve essere di almeno 5 ms.

Non c'è la DRAM e la FTL per forza è fatta risiedere nella SRAM. Il datasheet dell'ssd NON parla di mappatura presente nella nCache.
Mi tocca bacchettare Anandtech ;)
E' chiaro che sono ssd sperimentali e diversi da quelli moderni costituiti da Controller/DRAM/NAND.

Però grazie Black. Si impara sempre. Tipo non sapevo ci fossero ai tempi ssd privi di DRAM.


Ora proseguo nella lettura di https://freewechat.com/a/MzkzMjYyNDU4Mg==/2247484816/1
Chiaramente se prima mi ha confuso la nCache con la pSLC nel proseguo del testo considererà la cache SLC moderna... vediamo se dice le cose correttamente...

Inizia con il classico grafico dell'andamento della scrittura continuata su tutta la capienza dell'ssd, accompagnata da questa frase: "Parliamo innanzitutto di una situazione estremamente ideale: in questo mondo non esiste la scrittura casuale 4K e tutti i flussi IO sono blocchi sequenziali e di grandi dimensioni. Anche se è ridicolo, credetemi, dobbiamo costruire questo modello scandaloso e ridicolo prima di poter iniziare la discussione. ".

Se lo avessi davanti gli (o Le, magari è una ragazza nerd) direi che si è fermato alla superficie.
Vero che (lo dice anche THW nelle sue recensioni), il riempire con blocchi sequenziali un ssd da cima a fondo NON è un uso comune anzi è proprio stolkerare un ssd, ma
1) serve ovviamente a mettere in evidenza una cache di scrittura che altrimenti non si vedrebbe
ma sopratutto
2) un ssd pieno a 70-75% con buchi da cancellazione come un groviera (quindi un ssd "normale") si comporterebbe proprio così... mettendo sia in evidenza la cache, sia la scrittura diretta e lo stato di folding, quando usato un po più pesantemente.


proseguiamo.. cache SLC fissa VS simulazione del disco pieno (?)

Ah ok. cache fissa vs cache dinamica.
Spiegata discretamente, dai... più che altro perde l'ottica "evolutiva". Nel senso che non è una scelta tra le due... prima nasce la cache statica (nel senso che la pSLC essendo una funzione software, nasce creando un algoritmo che dedica in certo spazio fisso di celle emulabili, proprio come faceva nCache).
Poi (qualche anno dopo) con il progredire della capacità di programmazione, l'idea diventa di progettare e realizzare una pSLC dinamica dove il controller possa decidere la quantità variabile di spazio da dedicare alla cache di scrittura. Questa è la pSLC attuale, quella del concetto di folding esteso.

Una frase: " la cache SLC, troppo piccola, non riesce a coprire lo spazio richiesto dagli scenari applicativi moderni ed è inutile se non per accelerare i punti di esecuzione CDM e ASSSD; non risolve il problema delle perdite extra causate dall'espansione FTL in scenari complessi. Con lo sviluppo e il progresso della tecnologia, il mercato ha gradualmente smesso di riconoscere questo modello, per questo è emerso l'algoritmo full disk. ".

L'espansione della FTL (caro ragazzo o ragazza) è un non problema.
Quando la FTL (cioè la mappatura + tutti gli algoritmi di gestione) si espande oltre un certo limite (32 o 64 MB), si verifica (il parallelo può essere la paginazione di windows) un trasferimento di porzioni di FTL non modificate su Nand e il mantenimento della porzione di FTL variabile in DRAM (o RAM... ecco il perchè dei 32 MB).

Quindi in motivo per cui nel mercato si è affermata poi la pSLC dinamica (full disk viene chiamata da lui), è perchè si è ottimizzato l'algoritmo secondo le necessità degli usi consumer... reali (utilizzo base di nvme) e di marketing (i numeroniiii!!).

Scrive: "Ma l'algoritmo SLC full-disk non è onnipotente. Poiché tutti i blocchi rimanenti vengono convertiti in modalità SLC, dopo il burst del buffer, i dati nella cache SLC devono essere rilasciati durante la scrittura sui blocchi TLC: questa è la penalità di writeback. In questo momento, l'SSD deve affrontare un gran numero di letture e scritture REW, quindi possiamo vedere chiaramente che la velocità è diminuita in modo significativo: la velocità di scrittura diretta TLC dell'SN580 è di 1400 MB/S e la penalità di scrittura inversa è di soli 545 MB/S. Questa strategia rappresenta quindi un compromesso."

Grande verità. Più gli ssd attuali hanno una cache di scrittura dinamica grande, meno sono adatti a carichi di lavoro pesante.

2,2 fuori dalla cache

Ma guarda un po...questo è interessante, lo lascio per domani :D

Black (Wooden Law)
07-05-2025, 16:30
Se riesci linka la recensione di questo recensore cinese del 9100 PRO così mi faccio un idea delle differenze dello stato stazionario trovato rispetto a https://www.tomshardware.com/pc-components/ssds/samsung-9100-pro-ssd-review/2

È qui (https://www.bilibili.com/video/BV1dwidY1Eu7/?spm_id_from=333.1387.upload.video_card.click) la recensione del PM9E1 Liupen. Qui (https://space.bilibili.com/3537122193574340/upload/video) invece tutte le recensioni fatte finora da lui.

Dai, vediamo che diranno le future recensioni.

Sì, alla fine mi piace HOMOLAB per le sue recensioni ma ho scoperto di doverle prendere con le pinze per i risultati tutti unici a sé.


Inizialmente era la riscrittura dalla porzione di celle emulate SLC a TLC, stop, non avveniva direct-to write, ora è un insieme di cose, ecco perchè spesso si definisce: "stato di folding".

Il controller dell'ssd (nvme) attuale, in scrittura assidua e spazio libero ristretto (praticamente la normalità se si usa un ssd con qualche scrittura pesante), finita la cache pSLC disponibile, inizia a fare diverse cose in contemporanea:
- scrive in direct-to per continuare la scrittura ordinata dall'host
- sposta le pagine per liberare blocchi e predisporsi alla scrittura (GC)
- copia (sequenzialmente come scrivi su) il contenuto delle celle SLC in formato TLC (su ovviamente nuove celle che sono ovviamente ancora diverse da quelle del punto precedente)
- erase sulle celle emulate SLC
- creazione di nuovo spazio pSLC

Questo è lo stato di folding, che coincide con il massimo impegno del controller e dunque le prestazioni più basse dell'ssd in scrittura.

Capisco Liupen, quindi tu dici che il folding è soltanto la compressione dei blocchi SLC in TLC ma folding più le scritture su NAND flash TLC, lettura e cancellazione dei blocchi SLC, copia dei foldset da SLC a TLC e quant'altro è stato di folding. Mi verrebbe da dire che sia una distinzione non molto conosciuta, nel senso che non tutti fanno questa differenza ma ha assolutamente senso.

Riguardo la mappatura in nCache, hai ragione, ho letto AnandTech... riporta proprio quello, parola per parola come hai scritto.

Dovendo capire, quindi, sono andato a prendere una scheda di un vecchio ssd Sandisk 2010 SSD Sandisk P4 sata II (300) https://datasheet.octopart.com/SDSA4AH-032G-SanDisk-datasheet-10977758.pdf in cui è implementata la nCache originale.

Per questa parte penso che il ragionamento di AnandTech sia stato: "nel datasheet c'è scritto che i tipici blocchi di un SO sono da 4kB mentre quelli fisici di un SSD sono da più di 1MB. Data questa incongruenza che porta a un peggioramento di performance SanDisk ha deciso di creare la nCache per ricevere tutte le scritture 4kB" ma no, non ha scritto proprio questo. In realtà io non darei proprio per scontato che nel datasheet si intenda che nCache riceva le scritture 4kB, secondo me SanDisk voleva dire "nCache è fatta per migliorare le performance generali dell'SSD in scrittura viste le basse performance di quelle 4kB". Magari le scritture 4kB non erano "basse", ma sicuramente peggiori rispetto ad avere un rapporto 1:1 di dimensioni LBA-PBA.

Ha senso secondo te? Comunque sì, la mappa L2P non c'entra assolutamente nulla...

@Liupen
08-05-2025, 12:48
Capisco Liupen, quindi tu dici che il folding è soltanto la compressione dei blocchi SLC in TLC ma folding più le scritture su NAND flash TLC, lettura e cancellazione dei blocchi SLC, copia dei foldset da SLC a TLC e quant'altro è stato di folding. Mi verrebbe da dire che sia una distinzione non molto conosciuta, nel senso che non tutti fanno questa differenza ma ha assolutamente senso.

Per questa parte penso che il ragionamento di AnandTech sia stato: "nel datasheet c'è scritto che i tipici blocchi di un SO sono da 4kB mentre quelli fisici di un SSD sono da più di 1MB. Data questa incongruenza che porta a un peggioramento di performance SanDisk ha deciso di creare la nCache per ricevere tutte le scritture 4kB" ma no, non ha scritto proprio questo. In realtà io non darei proprio per scontato che nel datasheet si intenda che nCache riceva le scritture 4kB, secondo me SanDisk voleva dire "nCache è fatta per migliorare le performance generali dell'SSD in scrittura viste le basse performance di quelle 4kB". Magari le scritture 4kB non erano "basse", ma sicuramente peggiori rispetto ad avere un rapporto 1:1 di dimensioni LBA-PBA.

Ha senso secondo te? Comunque sì, la mappa L2P non c'entra assolutamente nulla...

Beh, non sono io che lo dico, sono terminologie che si usano nelle review.

Write Back, credo sia il termine tecnico corretto dal punto di vista accademico, ma ci hanno abituati a questo:

Official write specifications are only part of the performance picture. Most SSDs implement a write cache, which is a fast area of pseudo-SLC (single-bit) programmed flash that absorbs incoming data. Sustained write speeds can suffer tremendously once the workload spills outside of the cache and into the "native" TLC (three-bit) or QLC (four-bit) flash. Performance can suffer even more if the drive is forced to fold, which is the process of migrating data out of the cache in order to free up space for further incoming data.
We use Iometer to hammer the SSD with sequential writes for over 15 minutes to measure both the size of the write cache and performance after the cache is saturated. We also monitor cache recovery via multiple idle rounds. This process shows the performance of the drive in various states as well as the steady state write performance.
The 2TB CS2150 writes in the single-bit SLC mode at an average of almost 8.9 GB/s for about 50 seconds, indicating a 435GB cache. This is a large cache but by no means as large as it could be given the size of the drive. A smaller cache allows for a higher middle performance state, in this case a three-bit TLC mode that writes at around 2.15 GB/s. Finally, once the cache is completely full and needs to be emptied to allow access to the full drive capacity, that forces the drive to enter the slowest “folding” state. Here the drive writes at an average of 708 MB/s while juggling data.

https://www.tomshardware.com/pc-components/ssds/pny-cs2150-2tb-ssd-review/2

Fold: il processo di migrazione dei dati dalla cache per liberare spazio per ulteriori dati in ingresso
folding state: quando la cache è completamente piena e deve essere svuotata per consentire l'accesso all'intera capacità dell'unità, questa entra nello stato di "folding" più lento.

Cioè nel caso del “folding state” degli SSD, il termine non indica solo “piega” (per dire cache piena e copia su cella nativa) ma l’insieme delle attività — direct-to-write, garbage collection, flush pSLC, erase e ricreazione di cache — che il controller porta avanti contemporaneamente, raggiungendo il throughput minimo e segnando la fase di passaggio tra burst di velocità e ritorno allo stato di equilibrio della cache.

Tanto per creare un esempio parallelo sarebbe come dire "stallo" aerodinamico cioè la perdita di portanza e "stato di stallo" cioè gli effetti (perdita di controllo e oscillazioni.).

citazioni degli illustri ;)
https://linustechtips.com/topic/1269413-are-dramless-ssds-really-that-bad-stutter/#findComment-14213987
https://www.techpowerup.com/forums/threads/sk-hynix-platinum-p51-14-gb-s-pcie-gen-5-ssd-revealed.320614/post-5393322

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

Ha senso secondo me quando dici "nCache è fatta per migliorare le performance generali dell'SSD in scrittura viste le basse performance di quelle 4kB" è un escamotage per la velocità. Chi lo sà, magari all'inizio pensavano (vedi gli hdd) che la sola SRAM del controller fosse sufficiente a tenere la mappatura e la loro base era questa; quindi aveva senso trovare dei "trucchi" per migliorare le prestazioni utilizzando ciò che si aveva a disposizione, cioè le nand. Poi qualcun altro ha introdotto la DRAM nel sistema dell'ssd e allora la nCache è diventata altro. E' un ipotesi, chissà.
L'altra ipotesi, e mi pare più attinente, più giusta, e che la preoccupazione di questi tecnici fosse all'inizio la durata degli ssd. Hai visto che il P4 va da 8GB a 128GB. Figurati con gli algoritmi rudimentali di allora quanti TBW avevano. nCache è stata una trovata geniale per abbassare la WA e far durare più a lungo l'ssd.
Infatti in principio (vuoi per le prestazioni, vuoi per abbassase il WAF) è alla base anche degli ssd attuali.

Black (Wooden Law)
08-05-2025, 15:33
nCache è stata una trovata geniale per abbassare la WA e far durare più a lungo l'ssd.
Infatti in principio (vuoi per le prestazioni, vuoi per abbassase il WAF) è alla base anche degli ssd attuali.

Però nCache (mettendo caso che fosse lo stesso della cache SLC dinamica) con folding va in contrasto con l’aumento del WAF dovuta dal fatto che prima si scrive in SLC e poi in MLC. Quindi non so, magari c’è una riduzione ma lieve, boh.
Dynamic write acceleration may contribute to WAF because data may first be written as SLC and later be rewritten as MLC.
(Fonte (https://docs.media.bitpipe.com/io_12x/io_120157/item_1069530/brief_ssd_dynamic_write_accel.pdf))

@Liupen
08-05-2025, 22:07
Però nCache (mettendo caso che fosse lo stesso della cache SLC dinamica) con folding va in contrasto con l’aumento del WAF dovuta dal fatto che prima si scrive in SLC e poi in MLC. Quindi non so, magari c’è una riduzione ma lieve, boh.

(Fonte (https://docs.media.bitpipe.com/io_12x/io_120157/item_1069530/brief_ssd_dynamic_write_accel.pdf))

Diciamo che l'aspetto positivo della nCache è anche quello della pSLC pur essendo (ci tengo a dirlo nuovamente) due cose diverse.

Anche quà dice la stessa cosa, cioè che pSLC fà aumentare l'amplificazione di scrittura.
https://en.wikipedia.org/wiki/Write_amplification


Tuttavia non sono convinto, perchè WAF rappresenta un elemento assai importante (endurance ssd); non posso pensare a ssd QLC e PLC che vengono penalizzati nella TBW sull'altare delle prestazioni.
Quindi o la pSLC non influisce (va a pari se non migliora la WAF) oppure la peggiora ma in senso trascurabile.

Ci devo ragionare su...

La prima ipotesi trae spunto dalla nCache
La ri-scrittura o copia o fold avviene sequenzialmente su una porzione di celle corrispettive a quelle emulate ma in maniera organizzata, specie dati casuali (4KB). In questo caso la maggiore scrittura (copia celle SLC in TLC/QLC) viene mitigata o cambia di segno, per merito della migliore organizzazione delle pagine di celle native e dei relativi blocchi.

Proviamo un ragionamento deduttivo diverso.

Visto che maggiore è il fattore di amplificazione in scrittura, maggiore è la larghezza di banda occupata dal traffico in background (e peggiori sono le prestazioni del dell'SSD), la chiave è la riduzione del GC in background.
La pSLC per ridurre la WAF fà questo?

Si ci sono degli elementi ma, non sono in grado di dire che peso hanno

1) come per la nCache i dati casuali 4KB subiscono un fold sequenziale che li compatta. Più i dati sono compatti meno lavoro di CG in background si fà
2) la densità dei dati è migliore anche a livello di blocchi e quando il controller deve fare un erase si trova meno blocchi sparsi. Anche questo elemento migliora la WAF
3) ogni ciclo di GC sposta sia dati “caldi” sia “freddi” (wear-leveling), mentre il flush pSLC sposta solo pagine “hot” con conseguente netta riduzione del traffico totale se il carico è fortemente random

Black (Wooden Law)
08-05-2025, 22:35
Notizie (https://blocksandfiles.com/2025/05/08/sandisk-revenues-decline-with-mini-nand-glut/) su Sandisk: il primo report da quando ha “lasciato” WD è in negativo con i ricavi di 0,6% in meno anno per anno, 21% in meno trimestre per trimestre sul datacenter e 10% in meno (sempre trimestre per trimestre) sui prodotti consumer. Nonostante ciò, il CEO non è assolutamente deluso:
Sono soddisfatto dell'esecuzione del nostro team nel primo trimestre come azienda autonoma. L'innovazione di Sandisk è stata rafforzata con una forte rampa iniziale di BiCS8, la nostra ultima tecnologia progettata per offrire prestazioni leader del settore, efficienza energetica e densità.

Altri punti interessanti dell’articolo sono:
Goeckeler [il CEO] ha detto che la sua BiCS8 218-layer 3D NAND tecnologia sta producendo 2 Tbit QLC chip e questi sono "in qualifica con i migliori fornitori di servizi cloud per l'uso in SSD 128 terabyte e 256 terabyte." Ha menzionato i collegamenti PCIe Gen 5 e 6 per le unità QLC e pensa che il prodotto da 256TB potrebbe arrivare nel corso del prossimo anno, ovvero 2026.
E
C'è anche un nuovo controller SSD in arrivo.
"Abbiamo una nuova architettura in uscita nel prossimo paio di quarti che chiamiamo Stargate, nuovo ASIC [controller], disegno a foglio bianco e poi con BiCS8 QLC ... pensiamo che sarà un progetto dinamico", ha detto Goeckeler.

Fa anche piacere sentir dire che i dazi imposti da Trump non colpiscano esageratamente gli introiti:
Al momento, non ci sono dazi sui nostri prodotti tranne per le spedizioni dalla Cina agli Stati Uniti, che hanno tariffe del 27,5%. Per avere una prospettiva, circa il 20% dei nostri prodotti spediti negli Stati Uniti e oltre il 95% di quel reddito proviene da paesi diversi dalla Cina."

Black (Wooden Law)
09-05-2025, 00:28
Diciamo che l'aspetto positivo della nCache è anche quello della pSLC pur essendo (ci tengo a dirlo nuovamente) due cose diverse.

Anche quà dice la stessa cosa, cioè che pSLC fà aumentare l'amplificazione di scrittura.
https://en.wikipedia.org/wiki/Write_amplification


Tuttavia non sono convinto, perchè WAF rappresenta un elemento assai importante (endurance ssd); non posso pensare a ssd QLC e PLC che vengono penalizzati nella TBW sull'altare delle prestazioni.
Quindi o la pSLC non influisce (va a pari se non migliora la WAF) oppure la peggiora ma in senso trascurabile.

Ci devo ragionare su...

La prima ipotesi trae spunto dalla nCache
La ri-scrittura o copia o fold avviene sequenzialmente su una porzione di celle corrispettive a quelle emulate ma in maniera organizzata, specie dati casuali (4KB). In questo caso la maggiore scrittura (copia celle SLC in TLC/QLC) viene mitigata o cambia di segno, per merito della migliore organizzazione delle pagine di celle native e dei relativi blocchi.

Proviamo un ragionamento deduttivo diverso.

Visto che maggiore è il fattore di amplificazione in scrittura, maggiore è la larghezza di banda occupata dal traffico in background (e peggiori sono le prestazioni del dell'SSD), la chiave è la riduzione del GC in background.
La pSLC per ridurre la WAF fà questo?

Si ci sono degli elementi ma, non sono in grado di dire che peso hanno

1) come per la nCache i dati casuali 4KB subiscono un fold sequenziale che li compatta. Più i dati sono compatti meno lavoro di CG in background si fà
2) la densità dei dati è migliore anche a livello di blocchi e quando il controller deve fare un erase si trova meno blocchi sparsi. Anche questo elemento migliora la WAF
3) ogni ciclo di GC sposta sia dati “caldi” sia “freddi” (wear-leveling), mentre il flush pSLC sposta solo pagine “hot” con conseguente netta riduzione del traffico totale se il carico è fortemente random

Diciamo che hai esposto un bel dilemma. Effettivamente non ci avevo pensato, ma c’è un aumento e una riduzione del WAF allo stesso momento poiché vengono effettuate più scritture ma vengono anche organizzati meglio i blocchi di dati. Non ho prove numerate sull’aumento del WAF esposto da Micron nel suo PDF, ricordo solo una volta di un brevetto di Intel che disse che la media è di 0,4 ma che è fortemente dipendente dal workload e dal carico in background del controller. Mi sa che qualcuno con un decennio di esperienza si deve mettere a testare ed elaborare… :asd:

non posso pensare a ssd QLC e PLC che vengono penalizzati nella TBW sull'altare delle prestazioni.

Se può rassicurare Intel nel PDF (https://borecraft.com/PDF/Technical%20Digests/Intel%20192L%20PLC%20Long.pdf) delle 192L PLC ha detto di aver sviluppato un codice Gray (https://it.m.wikipedia.org/wiki/Codice_Gray) che alzava l’endurance della cache SLC statica fino a 250.000 PEC. Ovvio che è cache SLC statica, non la diffusissima dinamica…

@Liupen
09-05-2025, 10:37
Diciamo che hai esposto un bel dilemma. Effettivamente non ci avevo pensato, ma c’è un aumento e una riduzione del WAF allo stesso momento poiché vengono effettuate più scritture ma vengono anche organizzati meglio i blocchi di dati. Non ho prove numerate sull’aumento del WAF esposto da Micron nel suo PDF, ricordo solo una volta di un brevetto di Intel che disse che la media è di 0,4 ma che è fortemente dipendente dal workload e dal carico in background del controller. Mi sa che qualcuno con un decennio di esperienza si deve mettere a testare ed elaborare… :asd:



Se può rassicurare Intel nel PDF (https://borecraft.com/PDF/Technical%20Digests/Intel%20192L%20PLC%20Long.pdf) delle 192L PLC ha detto di aver sviluppato un codice Gray (https://it.m.wikipedia.org/wiki/Codice_Gray) che alzava l’endurance della cache SLC statica fino a 250.000 PEC. Ovvio che è cache SLC statica, non la diffusissima dinamica…

Che poi nello stesso pdf, frase dopo dice che non è certo dell'aumento :mbe:

Potrei realizzare un modello grafico anche perchè non saprei come iniziare a inibile la cache di scrittura in un nvme.
Dillo a Gabriel che ste cose le sa fare:D

Black (Wooden Law)
09-05-2025, 13:08
Che poi nello stesso pdf, frase dopo dice che non è certo dell'aumento :mbe:

Infatti nel documento scrivono “may” all’inizio che vuol dire “potrebbe” o comunque esprime una possibilità. Comunque dicono che se i dati non vengono toccati prima del folding l’aumento del WAF è di 2 (!) mentre se vengono riscritti o viene fatta qualche altra azione l’aumento del WAF è di 0.

@Liupen
09-05-2025, 15:24
Infatti nel documento scrivono “may” all’inizio che vuol dire “potrebbe” o comunque esprime una possibilità. Comunque dicono che se i dati non vengono toccati prima del folding l’aumento del WAF è di 2 (!) mentre se vengono riscritti o viene fatta qualche altra azione l’aumento del WAF è di 0.

Sto facendo il modello grafico ma già mi sono scoraggiato dalla quantità di cose da considerare... ahahah!
Ci provo ma ci va un po di tempo.

https://ibb.co/GQYz7g7d

Intanto googolando quà diciamo che molte conclusioni le avete raggiunte: https://www.techpowerup.com/forums/threads/effect-of-slc-caching-on-ssd-endurance.290690/page-3#posts

il testo dice esattamente

L'accelerazione dinamica della scrittura può contribuire al WAF poiché i dati possono essere prima scritti come SLC e successivamente riscritti come MLC. L'entità della differenza nel WAF è un fattore additivo compreso tra zero e due, a seconda delle condizioni di runtime. A condizione che si verifichino condizioni tali che un dato utente venga scritto come SLC e non venga né tagliato né riscritto prima della successiva migrazione a MLC, il fattore additivo nel WAF per tali dati sarebbe due. Se i dati utente sono stati riscritti o ridotti prima della migrazione da SLC a MLC, o se i dati sono stati originariamente scritti come MLC (come nel caso di carichi di lavoro sostenuti), il fattore additivo per tali dati sarebbe zero.

Compreso tra 0 e 2 (solo impatto WA del pSLC) perchè va da:
scrivo direttamente in celle MLC, quindi è zero
a:
scrivo in SLC e poi copiato/fold in MLC quindi ricopio scrivendo 2 volte il dato.

Esempio: devo scrivere 1GB di dati, quindi

Write host = 1 GB = 1

su ssd con pSLC (cache di scrittura):

Write NAND = 1 GB (su pSLC) + 1 GB (fold su MLC) = 2 GB = 2

WA = Write NAND / Write host = 2 / 1 = 2


Se il dato viene trimmato vuol dire che viene fissato li, rimane in SLC e mappato li. Allora non avvenendo la copia/fold la WA a causa di pSLC rimane zero.
Se il dato viene cancellato/invalidato, prima della mappatura e prima della copi/fold la WA a causa di pSLC rimane zero.

unnilennium
12-05-2025, 10:04
segnalo su amaz Fikwot FN955 2TB M.2 a 113.99 dovrebbe essere tra i consigliati se non sbaglio... rispetto al 530r come si comporta?

Black (Wooden Law)
12-05-2025, 13:22
Se il dato viene trimmato vuol dire che viene fissato li, rimane in SLC e mappato li. Allora non avvenendo la copia/fold la WA a causa di pSLC rimane zero.
Se il dato viene cancellato/invalidato, prima della mappatura e prima della copi/fold la WA a causa di pSLC rimane zero.

Top, direi tutto interessantissimo e su cui concordo. Poi oggi mi rileggo per bene tutta la discussione visto che ci sono dei punti molto interessanti e che vorrei ricordarmi. :asd:

Comunque, per inibire una cache SLC (visto che l’hai scritto in tuo commento prima di questo) dovresti usare un MPTool disattivandola manualmente, proprio come ha fatto Gabriel Ferraz su un Pichau Aldrin Pro (https://theoverclockingpage.com/2024/08/23/the-impact-of-slc-cache-in-performance-of-an-nvme-ssd-benchmarks-and-results/?lang=en) (IG5236 con CDT1B):
Selezionando ‘Pure XLC,’ la ‘X’ rappresenta la NAND nella sua forma nativa, come TLC, MLC o QLC nativo.
Il problema è che gli MPTool sono software difficili da ottenere per alcuni controller e se non fai le cose fatte per bene potresti mandare in paradiso l'SSD. O magari anche se fai le cose fatte per bene lo potresti mandare, quindi son cose abbastanza rischiose da fare.
segnalo su amaz Fikwot FN955 2TB M.2 a 113.99 dovrebbe essere tra i consigliati se non sbaglio... rispetto al 530r come si comporta?

Peggio, ovviamente, ma il 530R ha controller migliore, la DRAM e anche un prezzo maggiorato di 57 euro (costa 171 euro nel taglio da 2TB). Ciò non mette in cattiva luce l'FN955, semplicemente lo metto sotto di un gradino.

Personalmente non comprerei il 530R da 2TB neanche sotto tortura, il prezzo è troppo elevato rispetto ai suoi competitor nella stessa fascia di prezzo, guarda per esempio il P41 (https://www.amazon.it/SK-Platinum-interno-7-000MB-compatto/dp/B09QVD9V7R/ref=sr_1_2?__mk_it_IT=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=1L5ZOWM88YCQS&dib=eyJ2IjoiMSJ9.JvsTKnwfyoE0YEO3dW3MQTQSRtQ1Qv7CSO5XNHiWUqrrU_uCP2GLjvNsUyjP0ehEMo4D4bRPUoXOSWc5IIP-sk0Q80PJOxGfVaj4jbCbtibyTVhYRApAV4-3-OWBTo0kI6azoztnC5CvX9KUkChgwsJjvegZ3TdPh3Dbz54jFt5C7vLQ6wrsJzsYxbknULv6foLXRDV3s12MXG7HY9lI8HSOeg8I8jnHfD3eyEpxjydV2dJA2-DKDuqBgpov_RywQyT2G13sVcxyE279W3myU-5bLEI43x5kKBaN6RRB7K8.Oj1AimWGHawrSNkOJG2OTmnI1SE6yINMf2W21oEjYts&dib_tag=se&keywords=P41%2B2TB&qid=1747048856&sprefix=p41%2B2tb%2Caps%2C88&sr=8-2&ufe=app_do%3Aamzn1.fos.9d4f9b77-768c-4a4e-94ad-33674c20ab35&th=1) che ritengo superiore e che costa soltanto 143 euro. Però valuta anche se ti serve effettivamente un SSD DRAM-based: se l'uso è leggero con sopra SO, programmi, giochi, ecc., vai di FN955 altrimenti se l'uso è più impegnativo vai con il P41. Se l'uso è soltanto giochi o secondario neanche sto a dirlo, FN955 tutta la vita.

Black (Wooden Law)
13-05-2025, 10:55
Buona notizia (forse) per chi cerca SSD SATA: SK hynix annuncia il Silver S32 (successore del Gold S31) e l’NVMe P42 SSD Gen4 di fascia medio-bassa (5 GB/s in lettura). Qui (https://www.how2shout.com/news/sk-hynix-gold-p42-silver-s32-ssd-launch.html) la notizia.

L’S32 usa come controller l’SM2259XT (lo stesso del BX500) e NAND flash TLC (probabilmente le SK hynix V7 da 176L) mentre il P42 sempre NAND flash TLC V7 ma il controller Phison E21T che abbiamo visto su tanti SSD come il P3 e il P3 Plus, l’NV2, l’UD90, ecc. Non capisco la scelta di chiamare questo SSD “P42” facendolo intendere come successore del P41 ma vabbè.

Gli MSRP sono indecenti, $97/TB il P42 e $93/TB l’S32, ma se dovesse arrivare in Italia l’S32 lo recensirei molto probabilmente. Volevo fare lo stesso l’E55 di Silicon Power ma purtroppo non è spedito in Italia tramite il sito ufficiale (e su Amazon non è presente).

sbaffo
13-05-2025, 14:42
Buona notizia (forse) per chi cerca SSD SATA: SK hynix annuncia il Silver S32 (successore del Gold S31) e l’NVMe P42 SSD Gen4 di fascia medio-bassa (5 GB/s in lettura). Qui (https://www.how2shout.com/news/sk-hynix-gold-p42-silver-s32-ssd-launch.html) la notizia.

L’S32 usa come controller l’SM2259XT (lo stesso del BX500) e NAND flash TLC (probabilmente le SK hynix V7 da 176L) mentre il P42 sempre NAND flash TLC V7 ma il controller Phison E21T che abbiamo visto su tanti SSD come il P3 e il P3 Plus, l’NV2, l’UD90, ecc. Non capisco la scelta di chiamare questo SSD “P42” facendolo intendere come successore del P41 ma vabbè.

Gli MSRP sono indecenti, $97/TB il P42 e $93/TB l’S32, ma se dovesse arrivare in Italia l’S32 lo recensirei molto probabilmente. Volevo fare lo stesso l’E55 di Silicon Power ma purtroppo non è spedito in Italia tramite il sito ufficiale (e su Amazon non è presente). Da ciò che dici il p42 sembra inferiore al P41.
Però il marketting insegna che vale tutto pur di fregare i poll... ehm clienti.:rolleyes:

Black (Wooden Law)
13-05-2025, 17:06
Da ciò che dici il p42 sembra inferiore al P41.

Lo è, infatti io l'avrei chiamato "P41 Lite" piuttosto.
----------------------------------------------------------
Escono le prime recensioni (https://www.google.com/search?q=SN8100+review&rlz=1C1GCEU_itIT1162IT1162&oq=SN8100+review&gs_lcrp=EgZjaHJvbWUqCAgAEEUYJxg7MggIABBFGCcYOzIHCAEQABjvBdIBCDEzNTRqMGo3qAIAsAIA&sourceid=chrome&ie=UTF-8) dell'SSD teoricamente più veloce sul mercato: l'SN8100. 14,9 GB/s in sequenziale e 2,3 milioni di IOPS in random... :sofico:
Stessa configurazione del G5 ovvero SM2508 e NAND flash Kioxia BiCS8 TLC ma con performance migliori. Come mai? John di TweakTown dice:
Il nuovo SanDisk WD Black SN8100 2TB è un altro controller SMI SM2508 con BiCS8, molto simile al Kingston Fury Renegade G5 4TB che abbiamo recensito ieri. [...] Mentre il controller dell'SN8100 è tecnicamente basato sull'SM2508, è differente da tutti gli altri perché è stato modificato da SanDisk eseguendo l'IP SanDisk con feature proprietarie come nCache 4.0 e WD Black Gaming Mode fornendo un gran vantaggio su concorrenti configurati in modo simile. Questo SSD non è come gli altri, è almeno il 20% più potente di qualsiasi altro SSD basato su flash che abbiamo mai visto. Approcciando Optane.

Tralasciando l'ultima parte visto che questo SSD è lontano da Optane e il 20% è assolutamente falso, a quanto pare Sandisk ottimizzando il firmware è in stata in grado di spremere completamente le BiCS8 fornendo performance superiori rispetto anche alle B68S che fanno 95 MB/s per die in più (motivo per il quale ho scritto "teoricamente"; aspetto recensioni "migliori" come quelle di Tom's Hardware).

Black (Wooden Law)
13-05-2025, 20:33
La recensione di ComputerBase (https://www.computerbase.de/artikel/storage/wd-black-sn8100-ssd-im-test.92480/) (testata tedesca) dell'SN8100 da 2TB mostra che l'SSD è quasi un full-drive pSLC (nel taglio da 2TB ha probabilmente una cache SLC che si aggira sui 600GB) e che in direct-to-TLC fa circa 3.500 MB/s mentre in folding 1.500-2.000 MB/s. Direi degli ottimi numeri paragonandoli al cugino Fury Renegade G5.

Personalmente metto l'SN8100 sopra a tutti gli SSD Gen5 visti finora, sopra anche al re 4600.

giovanni69
14-05-2025, 08:34
WD_Black SN8100: è lui l'SSD M.2 più veloce del mondo (https://www.hwupgrade.it/news/storage/wd-black-sn8100-e-lui-l-ssd-m2-piu-veloce-del-mondo_138666.html)?

frafelix
14-05-2025, 09:02
Bisogna vedere se gli altri gen5 si abbasseranno di prezzo

Nicodemo Timoteo Taddeo
14-05-2025, 09:51
Tutti i Gen5 si abbasseranno di prezzo come è sempre stato e sarà. Aumenta la competizione sul prezzo, i prezzi vengono via via segati per restare competitivi.

Il punto semmai è quando succederà? Quanto tempo ci vorrà prima che arrivino a livelli "accettabili" per la gran massa? Ma anche quando questi dispositivi diventeranno veramente utili per quasi tutti? Allo stato attuale posso dire senza tema di smentita che ben poche realtà hanno necessità di tanta velocità, ci sono colli di bottiglia che ne limitano l'influenza nelle prestazioni del computer, direi che tranne rari casi in cui la spesa è effettivamente giustificabile, al momento acquistarli è più un esercizio di celodurismo :)

E in quest'ottica ben ci stanno i led a bordo del dissipatore...

Black (Wooden Law)
14-05-2025, 10:27
Ma anche quando questi dispositivi diventeranno veramente utili per quasi tutti? Allo stato attuale posso dire senza tema di smentita che ben poche realtà hanno necessità di tanta velocità, ci sono colli di bottiglia che ne limitano l'influenza nelle prestazioni del computer, direi che tranne rari casi in cui la spesa è effettivamente giustificabile, al momento acquistarli è più un esercizio di celodurismo :)

Penso che non saranno mai utili per "quasi tutti", quindi anche per l'utente medio o quasi. Alla fine anche i Gen4 e i Gen3 non sono necessari per "quasi tutti" ma semplicemente ci siamo adeguati a comprarli e riempirci di loro per l'abbassamento dei prezzi.

Che i Gen5 piacciano o meno per il calore e tanti altri motivi sono il futuro come lo saranno i Gen6, i Gen7, ecc., quindi ci ritroveremo per forza di cose pieni di questi SSD nei nuovi sistemi.

@Liupen
14-05-2025, 11:52
Ho finito la simulazione sulla WA.
Risultato? La cache pSLC AUMENTA la scrittura in background delle celle.
Nel mio esempio con un ssd costituito da 3 soli blocchi e una pSLC totalmente dinamica (come gli nvme ora) il rapporto è stato di ca 1,5; non raddoppia ma sta li in mezzo.
Posso dire che il GC che crea il fold ha versi contrastanti ma chiari: la sequenzialità dei 4KB riduce le pagine occupate e quindi compatta i dati sui blocchi (riduzione leggera WAF) ma la copia totale delle scritture in pSLC non si può trascurare ed aumenta la scritture delle nand.

Quindi alla fine la velocità ci viene fatta pagare, fortunatamente questi nvme durano assai.
I pregi della cache di scrittura sono descritti da Newmaxx molto bene:

La modalità SLC offre numerosi vantaggi, inclusi alcuni elencati in precedenza in questa risposta più ampia. Ad esempio, la modalità SLC è molto meno soggetta a errori di trasferimento dati dovuti a interruzioni di corrente. Garantisce inoltre protezione durante lo spostamento dei dati sulla memoria flash nativa e migliora le prestazioni poiché è possibile bypassare l'ECC con il copyback (folding). L'amplificazione in scrittura è ridotta poiché il copyback è sequenziale, il che è uno dei motivi per cui alcuni brevetti suddividono i carichi di lavoro per tipo, ad esempio le scritture casuali su SLC, che tengono conto dell'ECC anche in base al tipo di dati (se non altro per motivi di efficienza). Questo significa che ci sono molte ragioni per cui i produttori di SSD utilizzano la modalità SLC, non solo per le prestazioni in scrittura, ma anche perché la modalità pSLC è più veloce in tR (e quindi viene spesso utilizzata per i metadati). Ci sono ragioni per preferire la tecnologia direct-to-TLC, come la generazione di calore, ma in realtà sembra che molti produttori limitino artificialmente la velocità nativa del flash, ad esempio con il nuovo SN550 (o TLC SN530), l'870 QVO di Samsung, il P5 Plus, ecc. Il che indica certamente che sono interessati a fare affidamento sulla tecnologia SLC. Le implicazioni sulla durata sono più difficili da descrivere a fondo, anche se non credo che l'usura del flash sia un problema serio in questo caso.


WD_Black SN8100: è lui l'SSD M.2 più veloce del mondo?

Secondo ogni produttore, al lancio, il proprio è meglio degli altri.
Sembra essere confermata la programmazione del SM2508 ad avere una cache enorme che "crolla" letteralmente quando finisce: strategia orientata agli utenti consumer che vedono un ssd brillante con i piccoli trasferimenti e una reattività da numero1. Nei bench lunghi e di scrittura aggressiva, questo crollo, compromette ovviamente tutto quello che di buono si vede prima.

Black (Wooden Law)
14-05-2025, 12:07
Ho finito la simulazione sulla WA.
Risultato? La cache pSLC AUMENTA la scrittura in background delle celle.
Nel mio esempio con un ssd costituito da 3 soli blocchi e una pSLC totalmente dinamica (come gli nvme ora) il rapporto è stato di ca 1,5; non raddoppia ma sta li in mezzo.
Posso dire che il GC che crea il fold ha versi contrastanti ma chiari: la sequenzialità dei 4KB riduce le pagine occupate e quindi compatta i dati sui blocchi (riduzione leggera WAF) ma la copia totale delle scritture in pSLC non si può trascurare ed aumenta la scritture delle nand.

Quindi alla fine la velocità ci viene fatta pagare, fortunatamente questi nvme durano assai.

Ottimo e non ottimo a sapere direi, nel senso che adesso abbiamo la conferma che effettivamente la cache SLC dinamica aumenta il WAF. Grazie mille del test Liupen, non posso far altro che aggiungere questo tuo commento in prima pagina.

WD_Black SN8100: è lui l'SSD M.2 più veloce del mondo?

Secondo ogni produttore, al lancio, il proprio è meglio degli altri.
Sembra essere confermata la programmazione del SM2508 ad avere una cache enorme che "crolla" letteralmente quando finisce: strategia orientata agli utenti consumer che vedono un ssd brillante con i piccoli trasferimenti e una reattività da numero1. Nei bench lunghi e di scrittura aggressiva, questo crollo, compromette ovviamente tutto quello che di buono si vede prima.

Nel frattempo Phison ha ascoltato le nostre parole e se n'è uscita con il PCMark10 (https://www.tomshardware.com/pc-components/ssds/exclusive-phison-e28-ssd-trashes-the-fastest-ssds-on-the-market-in-new-benchmark) (test che odio e che trovo superstupido e irrilevante) più alto di sempre con l'E28:
Il punteggio PCMark 10 ha indicato che il Phison E28 ha avuto una performance significativamente superiori ai suoi competitori. è stato approssimativamente più veloce del 18% rispetto al Samsung 9100 Pro e al Micron 4600. Inoltre, il Phison E28 ha sorpassato il Predator GM9000 [SM2508 con B58R) del 32%.

@Liupen
14-05-2025, 14:21
Se però il WD ..ops Sandisk SN8100 risultasse in PCMark 10 il 15% più veloce del Samsung 9100 Pro? :D

Black (Wooden Law)
14-05-2025, 17:39
Se però il WD ..ops Sandisk SN8100 risultasse in PCMark 10 il 15% più veloce del Samsung 9100 Pro? :D

Si elimina quello scempio di PCMark 10 dalle recensioni. :D
Firmerei una petizione per farlo.

giovanni69
14-05-2025, 17:47
WD_Black SN8100: è lui l'SSD M.2 più veloce del mondo?

Secondo ogni produttore, al lancio, il proprio è meglio degli altri.
Sembra essere confermata la programmazione del SM2508 ad avere una cache enorme che "crolla" letteralmente quando finisce: strategia orientata agli utenti consumer che vedono un ssd brillante con i piccoli trasferimenti e una reattività da numero1. Nei bench lunghi e di scrittura aggressiva, questo crollo, compromette ovviamente tutto quello che di buono si vede prima.

...come dire, se intendo bene, che se usato per cercare vantaggi prestazionali nelle clonazioni, potrebbe essere non molto diverso dai migliori Gen4 già esistenti.

Black (Wooden Law)
14-05-2025, 19:40
...come dire, se intendo bene, che se usato per cercare vantaggi prestazionali nelle clonazioni, potrebbe essere non molto diverso dai migliori Gen4 già esistenti.

Dipende se la clonazione usa la cache SLC (e quindi fa scritture intensive), ma teoricamente sì, lo fa. Dopo la cache SLC tra il miglior PCIe 4.0 (il P41 secondo me) e un PCIe 5.0 ci passano più di 2 GB/s, anche se c'è da tener conto del taglio degli SSD, eventuale folding, ecc.

@Liupen
14-05-2025, 22:14
Si elimina quello scempio di PCMark 10 dalle recensioni. :D
Firmerei una petizione per farlo.

Ecco, togli il bench del momento.. son tutti li a farlo, anche i cinesi l'hanno acquistato :Prrr:

Perchè ho visto la recensione di Techtesters
a far due conti matematici +15-16 ...ci si ritrova sempre con "siamo lì"

...come dire, se intendo bene, che se usato per cercare vantaggi prestazionali nelle clonazioni, potrebbe essere non molto diverso dai migliori Gen4 già esistenti.

Si esatto. Non gli far fare scritture pesanti over cache (che si riduce poi al crescere del riempimento) ed è il numero unissimo.




Black butta un occhio a questo.

Molto semplicemente, la QD è il numero di richieste I/O che possono essere messe in coda contemporaneamente. Se abbiamo quindi una QD di 5 vuol dire che ci sono 5 richieste I/O nello stesso momento. I thread, invece, sono i thread della CPU e la definizione di “thread” è “una suddivisione di un processo in due o più filoni (istanze) o sottoprocessi” [10].
Se dovessi fare un esempio lo farei con delle persone e se il benchmark che stessimo andando ad eseguire fosse Q4T4 (quindi QD di 4 e 4 thread) vorrebbe dire che avremmo 4 persone (thread) che starebbero chiedendo 4 informazioni allo stesso momento (QD).
A maggiore QD e thread abbiamo maggiori performance; ecco svelato il motivo per il quale nelle operazioni “normali” (che per il 90% dei casi non superano una QD di 4 [11, pagina 12]) gli SSD che sono pubblicizzati come 14,9 GB/s ne fanno magari molti meno.
… ne fanno molti meno se i dati che stiamo scrivendo o leggendo sono sequenziali, però, ovvero i blocchi sono contigui uno all’altro al termine e inizio delle operazioni, altrimenti stiamo parlando di operazioni randomiche dove la velocità è molto più bassa. Per esempio, un’operazione sequenziale è costituita dalla fine del blocco 257 (numero completamente a caso) e l’inizio di quello 258, mentre un’operazione randomica è costituita dalla fine del blocco 355 e l’inizio del 122 (ricordandoci comunque che le operazioni di scrittura vengono eseguite a livello di pagina e non di blocco), quindi le operazioni randomiche sono per forza di cosa molto più lente. Il vantaggio per le operazioni sequenziali è ancora più maggiore se si parla di pagine nello stesso blocco: magari non serve passare dal 257 al 258 ma dalla pagina 25 del 257 alla pagina 26 del 257.



QD e Thread sono entrambe comandi (di lettura o scrittura) in I/0 operazioni al secondo verso l'ssd; SSD costituito come modello da controller (che elabora) e pacchetti NAND (che memorizzano il dato).
QD rappresenta la richiesta (comando) di lettura o scrittura contemporanee che il controller deve vagliare una a una, ma non essendo in grado di fare in contemporanea, mette in una coda più o meno organizzata. NCQ di AHCI supporta solo massimo 32 comandi, NVMe supporta migliaia di code parallele e decine di migliaia di comandi per coda.
Thread (la storia della cpu è una cagata che si trova online, bisogna spiegare la pipe PCIe/DMA, ma il concetto può essere molto semplice: i comandi vengono gestiti dal sistema operativo tramite protocollo AHCI e NVME) a differenza del singolo comando I/0, Thread è l'operazione (la stessa differenza dal dire una singola parola ripetuta 10 volte e dire una frase di 10 parole). Thread è un operazione un comando o istruzioni di tanti comandi I/0 quanti si vuole a realizzare una coda o no (se il comando è singolo), e che ha un inizio e un termine a cui il controller risponde alla fine con "eseguito!". Inoltre più thread possono essere sia di lettura che di scrittura contemporaneamente.


Tanto per schematizzare in modo supersintetico :mc: :

QD 8 = 1(realtime) + (coda) 0-0-0-0-0-1-1

3 Thread =[1-0-0-0-0-0-1-1](lettura) + [1-1-0-1](scrittura) + [1-0-0-0-0-0-1-1](lettura)

In Seq1M Q8T3 si utilizza un file da 1MiB (1024 KB) da leggere in 3 "pacchetti" ognuno contenete 8 comandi in coda.


Gli effetti di QD e Thread sono indicatori di qualcosa.

QD cioè il tempo, quindi la velocità di svolgimento dell'operazione è diretta conseguenza della capacità di elaborazione del controller dell'ssd.
Inoltre una coda bassa QD 1 ad esempio può essere proporzionalmente più lenta di una coda alta QD 32 ad esempio.
tipo un nvme con QD 1 in lettura di 55 MB/s sviluppa poi un QD 32 di 3000 MB/s, ma 55x32 ≠ 3000; il perchè è legato alla latenza. Coda alta assorbe il rallentamento della latenza iniziale ad eseguire il comando dato.

Thread invece è conseguenza diretta della capacità di controller e chip NAND di leggere o scrivere contemporaneamente (parallelismo).
Quando ho un ssd con un pacchetto di chip di memoria ho almeno 2 canali da sfruttare (in entrata e in uscita anche contemporaneamente). Quindi posso leggere il dato che mi serve o scriverlo come farebbe un array di dischi. Capacità del controller, firmware ben fatto, disponibilità di più pacchetti NAND, offrono un parallelismo maggiore e migliori prestazioni a parità di coda.


Temo che il motivo per cui: gli SSD che sono pubblicizzati come 14,9 GB/s ne fanno magari molti meno, sia perchè sono benchmark fatti su sistemi preparati ad hoc, su ssd secondari e con bench a cui si dà una priorità da OS (insomma le condizioni migliori) e quando normalmente non ci arrivano è per la fuffa da marketing.


Inoltre non è lo spostamento di indirizzo di pagine e blocco che determina la differenza di velocità tra dati casuali e dati sequenziali. E' molto vicino, si intuisce ma non è centrato.
Se si parla di indirizzi di mappatura logica, boh, non c'è differenza perchè cambiare un puntatore su SRAM (o RAM di sistema) di un qualsiasi valore è immediato.
Su SSD concettualmente anche; scrivere un dato su una cella su un altra, ecc, ovunque si trovi, è elettronicamente uguale per un controller.
La differenza di velocità di lettura e scrittura tra, esempio 1024 I/0 da 4K e 4 MB (256x4=4096KB=4MB) sta nella morfologia (grandezza) ma anche nel tipo di comando.

Anche in questo caso per farla molto supersintetica sulla scrittura che è più intuitiva:

Quando arriva 1 comando sequenziale da 4MB dall'host (Windows) il controller dell'ssd cancella 1 blocco NAND e scriverà successivamente il dato sulle pagine dell'intero blocco ad una velocità alta e costante.

Di contro quando arrivano comandi da 4K il controller non sa a priori quanti 4K saranno. Ogni volta che arriva un comando casuale il contoller cerca un blocco libero (se ssd è vergine e ne ha ancora) oppure dovrà fare Garbage Collection per liberare pagine per un numero imprecisato di 4K. Nel nostro esempio dati sequenziali da 1024 x 4K richiederanno più Garbage Collection e blocchi liberi del corrispettivo sequenziale.
Piccoli blocchi (4 KiB) spesso ricadono in pagine diverse e attivano più unità di parallelismo NAND con un overhead ma anche latenza assai maggiore del singolo trasferimento sequenziale.


Leggo anche qui:
- cache SLC ibrida: chiamata anche "TurboWrite" da Samsung e "nCache" da WD, la cache SLC ibrida è formata da una porzione di cache SLC statica e una porzione di cache SLC dinamica fondendo i due tipi insieme. Non ci sono numeri su quanto aumenti la durata questo tipo di cache SLC.

Non credo siano forme ibride di cache sono solo idee di cache diverse da quella che si è affermata poi (per semplicità pSLC).
nCache 2.0 è una cache direttamente sui die, in parte assorbono in SLC e poi trasferiscono in automatico sulla parte MLC (TLC/QLC)
nCache 3 e 4 è una pSLC statica + dinamica o solo dinamica (quella odierna)
Turbo Write è una cache creata via software opzionando la RAM di sistema (ma guarda...proprio l'idea dell' HMB :D ).
Idem Dynamic Wrtite di Micron..

Black (Wooden Law)
14-05-2025, 23:44
Thread (la storia della cpu è una cagata che si trova online, bisogna spiegare la pipe PCIe/DMA, ma il concetto può essere molto semplice: i comandi vengono gestiti dal sistema operativo tramite protocollo AHCI e NVME) a differenza del singolo comando I/0, Thread è l'operazione (la stessa differenza dal dire una singola parola ripetuta 10 volte e dire una frase di 10 parole). Thread è un operazione un comando o istruzioni di tanti comandi I/0 quanti si vuole a realizzare una coda o no (se il comando è singolo), e che ha un inizio e un termine a cui il controller risponde alla fine con "eseguito!". Inoltre più thread possono essere sia di lettura che di scrittura contemporaneamente. […] In Seq1M Q8T3 si utilizza un file da 1MiB (1024 KB) da leggere in 3 "pacchetti" ognuno contenete 8 comandi in coda.

Ma questo non è lo stesso di quello che ho scritto io? Forse Q4T4 non è il miglior esempio del mondo visto che può far confusione ma quello che io intendo in prima pagina è 4 richieste I/O in coda per ogni thread. Non potrebbe essere una richiesta I/O in coda per ogni thread, altrimenti casi come Q8T3 non esisterebbero visto che ogni thread avrebbe più richieste I/O in coda.

Per quanto riguarda la definizione in sé di thread, non pensavo ce ne fosse una diversa da quella “canonica” della CPU; sapresti argomentare? Intanto procedo a correggere, ti ringrazio Liupen.

Temo che il motivo per cui: gli SSD che sono pubblicizzati come 14,9 GB/s ne fanno magari molti meno, sia perchè sono benchmark fatti su sistemi preparati ad hoc, su ssd secondari e con bench a cui si dà una priorità da OS (insomma le condizioni migliori) e quando normalmente non ci arrivano è per la fuffa da marketing.

Sicuramente per le velocità di picco specificate dai produttori c’è di mezzo il fatto di usare benchmark dedicati all’SSD ma il principale motivo, secondo me, è proprio la quantità spropositata di richieste I/O in coda e thread. Lo possiamo notare proprio nelle recensioni che è così, perché sappiamo entrambi che qualsiasi SSD in Q1T1 (per esempio) farà sempre peggio rispetto a Q32T32 o anche peggio (vedi Tom’s Hardware che in alcuni test usa addirittura QD256).

Inoltre non è lo spostamento di indirizzo di pagine e blocco che determina la differenza di velocità tra dati casuali e dati sequenziali. E' molto vicino, si intuisce ma non è centrato.
Se si parla di indirizzi di mappatura logica, boh, non c'è differenza perchè cambiare un puntatore su SRAM (o RAM di sistema) di un qualsiasi valore è immediato.
Su SSD concettualmente anche; scrivere un dato su una cella su un altra, ecc, ovunque si trovi, è elettronicamente uguale per un controller.
La differenza di velocità di lettura e scrittura tra, esempio 1024 I/0 da 4K e 4 MB (256x4=4096KB=4MB) sta nella morfologia (grandezza) ma anche nel tipo di comando.

Anche in questo caso per farla molto supersintetica sulla scrittura che è più intuitiva:

Quando arriva 1 comando sequenziale da 4MB dall'host (Windows) il controller dell'ssd cancella 1 blocco NAND e scriverà successivamente il dato sulle pagine dell'intero blocco ad una velocità alta e costante.

Di contro quando arrivano comandi da 4K il controller non sa a priori quanti 4K saranno. Ogni volta che arriva un comando casuale il contoller cerca un blocco libero (se ssd è vergine e ne ha ancora) oppure dovrà fare Garbage Collection per liberare pagine per un numero imprecisato di 4K. Nel nostro esempio dati sequenziali da 1024 x 4K richiederanno più Garbage Collection e blocchi liberi del corrispettivo sequenziale.
Piccoli blocchi (4 KiB) spesso ricadono in pagine diverse e attivano più unità di parallelismo NAND con un overhead ma anche latenza assai maggiore del singolo trasferimento sequenziale.

Su questo hai completamente ragione al 100%, purtroppo sono rimasto che gli HDD sono più lenti con gli I/O randomici rispetto agli I/O sequenziali e ho applicato lo stesso concetto agli SSD, ma a seguito della stesura della prima pagina ho letto questo articolo di Code Capsule (https://codecapsule.com/2014/02/12/coding-for-ssds-part-5-access-patterns-and-system-optimizations/) (che nonostante sia del 2014 dovrebbe essere ancora buono visto che non penso sia cambiato il pattern degli I/O randomici e sequenziali) che mi ha confermato il contrario: le scritture randomiche sono più lente di quelle sequenziali se hanno una dimensione piccola, altrimenti performano come le scritture sequenziali.

Non credo siano forme ibride di cache sono solo idee di cache diverse da quella che si è affermata poi (per semplicità pSLC).
nCache 2.0 è una cache direttamente sui die, in parte assorbono in SLC e poi trasferiscono in automatico sulla parte MLC (TLC/QLC)
nCache 3 e 4 è una pSLC statica + dinamica o solo dinamica (quella odierna)
Turbo Write è una cache creata via software opzionando la RAM di sistema (ma guarda...proprio l'idea dell' HMB ).
Idem Dynamic Wrtite di Micron..

Su nCache hai ragione ma io ho scritto che indica la cache SLC ibrida perché parlo di nCache 4.0 che è l’ultimo modello, non parlo di nCache, nCache 2.0 o nCache 3.0. :D
Giusta accortezza, tuttavia, infatti domani correggo scrivendo “nCache 4.0”.

Per quanto concerne TurboWrite, invece, ti cito il PDF di Samsung (https://download.semiconductor.samsung.com/resources/white-paper/Samsung_SSD_TurboWrite_Whitepaper_EN.pdf) sull’840 (… purtroppo, è l’unico che ho trovato):
TurboWrite Technology creates a high-performance write buffer area within the drive that simulates high-performance SLC.

Dynamic Write Acceleration (https://docs.media.bitpipe.com/io_12x/io_120157/item_1069530/brief_ssd_dynamic_write_accel.pdf), invece, non c’entra né con la RAM né con la cache SLC ibrida, è semplicemente il nome di Micron per la cache SLC dinamica.
Acceleration is achieved using on-the-fly mode, switching between SLC and MLC in the firmware to create a dynamic pool of high-speed SLC NAND blocks.

@Liupen
15-05-2025, 11:36
Ma questo non è lo stesso di quello che ho scritto io? Forse Q4T4 non è il miglior esempio del mondo visto che può far confusione ma quello che io intendo in prima pagina è 4 richieste I/O in coda per ogni thread. Non potrebbe essere una richiesta I/O in coda per ogni thread, altrimenti casi come Q8T3 non esisterebbero visto che ogni thread avrebbe più richieste I/O in coda.

Per quanto riguarda la definizione in sé di thread, non pensavo ce ne fosse una diversa da quella “canonica” della CPU; sapresti argomentare? Intanto procedo a correggere, ti ringrazio Liupen.

Sono più io che ringrazio te nell'aver modo di poter dialogare di ssd su temi un po più tecnici ma che se acquisiti possono portare il lettore a capire più approfonditamente i numeri che legge ad esempio confrontando due schermate di crystaldiskmark.

Ti parlo di concetti filtrati e semplificati, perchè non sono un informatico.

4 richieste I/O in coda per ogni thread = Q4T4 è ok

Però però...lascia stare le definizioni che leggi, cerca di capire la logica prima (scusa se mi permetto).

La definizione di Thread per il benchmark dell'ssd o comunque per gli I/0 all'ssd non è la definizione generale di Thread di CPU. Ovviamente si parla di significati uguali nel modo dell'informatica, nella sostanza, ma diversi nei modi.

L'esempio classico che si può fare, per il thread dell'ssd, a cui sono legato da sempre, è la biblioteca.
C'è un indice centrale su una scrivania e tanti scaffali attorno. Gli scaffali sono organizzati a zone: astronomia, narrativa, fantasy, geologia, ecc ecc
Altra cosa da immaginare e che tutti gli scaffali a raggiera sono raggiungibile dalle mie braccia.

Una richiesta di input/output (I/O in generale, senza distinguere tra sequenziale e casuale) è "vado a prendere il libro nello scaffale XY" oppure "vado a posare il libro sullo scaffale XY".
Quando (Q4T4) ho Q4 cioè 4 richieste contemporanee di consultare o mettere a posto un libro, ed io son da solo, io mi organizzo una coda di attività. Più mi muovo veloce con le braccia, più velocemente consulto i libri o li rimetto a posto sul relativo scaffale XY.
Passiamo ora dalla definizione di "richieste I/O" a quella di Thread.
Devo ad esempio fare una ricerca su come si è evolvuta la Terra nelle ere.
Mi serve contemporaneamente per la mia ricerca, un libro da scaffale astronomia e uno da scaffale geologia. Gli scaffali in questo caso sono XY e ZW.
Essendo due scaffali diversi, posso usare un braccio per XY e l'altro per ZW ottenendo quello che mi serve (o se "scrivo" rimettendo a posto i due libri).

Le richieste I/0 sono gli elementi grezzi del lavoro (poso libri/prendo libri).
Il Thread è il lavoro che si richiede (la ricerca/la conservazione della ricerca).

Il primo elemento e la coda che ne deriva, non c'è mai da sola, deve essere sempre finalizzata in almeno un Thread.. un lavoro, un obbiettivo.

Ora, capito il senso logico, pensiamo a chi gestisce le richieste e le istruzioni.
Quì scomodi le definizioni più tecniche.

Ogni Thread dell'ssd o che coinvolge la memoria non volatile, non passa dalla CPU di sistema ma viene elaborata mediante Direct Memory Access (DMA).

In generale, senza guardare le differenze di protocollo (AHCI/NVMe), l'host presenta il comando (lettura o scrittura) in Thread che vengono organizzati in varie richieste I/0 mediante DMA.
DMA mette in comunicazione l'host con il controller dell'ssd.
Il numero di comandi I/O pendenti che l’host può mettere in coda verso il controller sono massimo 32 par AHCI e di miglioia per nvme che inoltra supporta anche comandi di lettura e scrittura contemporanei.
Il controller SSD, senza disturbare la CPU di sistema, legge quella coda (sempre tramite DMA), esegue il trasferimento dati NAND da e per la RAM (DMA dei dati), poi scrive l’esito.
NB. durante questa operazione il controller gestisce come sappiamo anche il GC, il WL ecc oltre ad aggiornare la mappatura su SRAM o RAM di sistema.

Rifacendola semplice, il "lavoro" dell'utente, quindi l'host, gestisce il/i Thread mediante l'interfaccia [AHCI stà per SATA ma è più corretto dire AHCI] AHCI VS NVMe; le singole istruzioni che realizzano il/i Thread sono gestiti solo internamente all'host che ne assegna priorità, ne organizza le QD e tante altre cose molto tecniche che ora si può trascurare.
Il controller dell'ssd non gestisce le code ma può gestire più comandi in parallelo (Thread), in modo più o meno intelligente a seconda del numero di chip nand e dalle caratteristiche computazionali proprie.
Il controller poi ovviamente ha il compito di dare il comando "eseguito" all'host.


Sicuramente per le velocità di picco specificate dai produttori c’è di mezzo il fatto di usare benchmark dedicati all’SSD ma il principale motivo, secondo me, è proprio la quantità spropositata di richieste I/O in coda e thread. Lo possiamo notare proprio nelle recensioni che è così, perché sappiamo entrambi che qualsiasi SSD in Q1T1 (per esempio) farà sempre peggio rispetto a Q32T32 o anche peggio (vedi Tom’s Hardware che in alcuni test usa addirittura QD256).

Parlavi però delle prestazioni sequenziali massime pubblicate per un ssd, non di come si comportano al variare del tipo di bench.
Almeno, così mi era parso di capire.



Su nCache hai ragione ma io ho scritto che indica la cache SLC ibrida perché parlo di nCache 4.0 che è l’ultimo modello non parlo di nCache, nCache 2.0 o nCache 3.0. :D
Giusta accortezza, tuttavia, infatti domani correggo scrivendo “nCache 4.0”.

Per quanto concerne TurboWrite, invece, ti cito il PDF di Samsung sull’840 (… purtroppo, è l’unico che ho trovato):


Dynamic Write Acceleration, invece, non c’entra né con la RAM né con la cache SLC ibrida, è semplicemente il nome di Micron per la cache SLC dinamica.

Forse, ma controlla che vado a memoria, la nCache 3.0 è una pSLC con una parte statica e una dinamica, mentre la versione 4.0 per le QLC è poi solo dinamica.

Riguardo le cache di boost di Samsung colpa mia ho confuso il turbowrite con la rapidmode; ma quando ho letto ibride, mi è venuto in mente la forma software di accelerazione.

Black (Wooden Law)
16-05-2025, 20:46
Eccomi Liupen. Perdonami, ero fuori casa in questi due giorni.
Rifacendola semplice, il "lavoro" dell'utente, quindi l'host, gestisce il/i Thread mediante l'interfaccia [AHCI stà per SATA ma è più corretto dire AHCI] AHCI VS NVMe; le singole istruzioni che realizzano il/i Thread sono gestiti solo internamente all'host che ne assegna priorità, ne organizza le QD e tante altre cose molto tecniche che ora si può trascurare.
Il controller dell'ssd non gestisce le code ma può gestire più comandi in parallelo (Thread), in modo più o meno intelligente a seconda del numero di chip nand e dalle caratteristiche computazionali proprie.
Il controller poi ovviamente ha il compito di dare il comando "eseguito" all'host.
Bene, ora che hai fornito questa spiegazione direi che ho afferrato il concetto. Facendo un riassunto (dimmi se sbaglio qualcosa):
- QD: profondità di coda ossia quantitativo di richieste I/O richieste dall’applicazione. Più vengono accumulate richieste più la coda aumenta;
- thread: insieme di richieste I/O organizzate in QD;

Per fare un esempio con un’applicazione: l’applicazione esegue più richieste I/O -> queste richieste I/O formano una coda “profonda” -> più code vengono raggruppate in un thread -> l’host (o meglio, il SO) comunica al controller dell’SSD che ci sono dei thread da gestire ma lo fa tramite DMA, ossia con CPU dormiente (:asd:) -> l’SSD sempre tramite DMA prende i thread -> l’SSD “risolve” i thread per i fatti suoi (o in caso di SSD DRAM-less con HMB risolve i thread con un po’ di RAM).

Comunque, per il numero massimo di QD per thread, TechTarget (https://www.techtarget.com/searchstorage/definition/queue-depth) dice:

• I dispositivi Serial ATA o SATA possono supportare una coda di comando con una profondità di coda di 32 comandi.
• I dispositivi Serial-attached SCSI o SAS possono supportare una coda di comando con una profondità di coda di 256 comandi.
• I dispositivi Nonvolatile memory express o NVMe possono supportare un numero massimo di 65.535 code di comando con una profondità di coda fino a 65.536 comandi per coda.

Da qui presumo:
1) TechTarget ha le idee abbastanza confuse;
2) TechTarget ha fatto confusione con i termini per gli SSD NVMe;
3) TechTarget con “coda di comando” non intende i thread ma altro di cui non so. Secondo me sbaglia e la verità è che (penso) ci sia un numero “illimitato”¹ di thread ma non ovviamente di richieste I/O, quindi NVMe può creare massimo 65.536 di richieste I/O per thread, SAS 256 richieste I/O per thread, ecc.
————————————————-
¹: ovviamente non sono illimitati, penso che dipenda dall’applicazione, dalle capacità del controller dell’SSD, dal SO, ecc.
Parlavi però delle prestazioni sequenziali massime pubblicate per un ssd, non di come si comportano al variare del tipo di bench.
Almeno, così mi era parso di capire.

Sì, esatto. Quello che io voglio dire è: 14,9 GB/s (solo per alcuni SSD ovviamente) sono raggiungibili ma principalmente per le impostazioni del benchmark come alta QD e tanti thread, poi ci sono benchmark specifici e altri fattori.
Forse, ma controlla che vado a memoria, la nCache 3.0 è una pSLC con una parte statica e una dinamica, mentre la versione 4.0 per le QLC è poi solo dinamica.

No Liupen, teoricamente nCache, nCache 2.0 e nCache 3.0 son tutte e tre cache SLC statiche, semplicemente perché su tutti i modelli di SSD a cui sono state implementate è così, anche per l’SN750 dove la cache SLC è di ~45GB. nCache 4.0, invece, è una cache SLC ibrida visto l’SN850 (primo modello su cui è stata implementata se ricordo bene). Non so darti molte fonti su quest’ultima semplicemente perché WD non lo dice ma se cerchi “nCache 4.0 hybrid SLC (https://www.google.com/search?q=nCache+4.0+hybrid+SLC&client=safari&sca_esv=7ce7144faa458147&hl=en-gb&sxsrf=AHTn8zpmJL5gEfUJ-QRF6A-D2H6EojE72g%3A1747420974540&ei=LocnaL3iII7vi-gPxdbDuQM&oq=nCache+4.0+hybrid+SLC&gs_lp=EhNtb2JpbGUtZ3dzLXdpei1zZXJwIhVuQ2FjaGUgNC4wIGh5YnJpZCBTTEMyBBAjGCcyBRAhGKABSOM-UK8NWLc7cAl4AZABAJgBcKAB9AmqAQQxMS4zuAEDyAEA-AEBmAIToALBB8ICChAAGLADGNYEGEfCAgUQABjvBcICCBAAGIAEGKIEwgIIEAAYogQYiQXCAgcQIxiwAhgnwgIKECEYoAEYwwQYCsICCBAhGKABGMMEmAMAiAYBkAYIkgcEMTcuMqAHwy-yBwM4LjK4B58HwgcHMC45LjkuMcgHOQ&sclient=mobile-gws-wiz-serp)” su Google vedi che trovi “hybrid SLC” come parole chiave negli articoli (mentre con nCache 3.0 no).

@Liupen
17-05-2025, 01:58
Per fare un esempio con un’applicazione: l’applicazione esegue più richieste I/O -> queste richieste I/O formano una coda “profonda” -> più code vengono raggruppate in un thread -> l’host (o meglio, il SO) comunica al controller dell’SSD che ci sono dei thread da gestire ma lo fa tramite DMA, ossia con CPU dormiente (:asd:) -> l’SSD sempre tramite DMA prende i thread -> l’SSD “risolve” i thread per i fatti suoi (o in caso di SSD DRAM-less con HMB risolve i thread con un po’ di RAM).

Si :D l'applicazione è il Thread che a sua volta è formato da 1 o più di una richieste I/0 (di lettura o scrittura) che possono formare una coda.



L'host tramite DMA, lancia una serie di letture o scritture.. "lavori" come li ho definiti su -> che sono spacchettabili in richieste I/0 da mettere in fila (richieste I/O formano una coda “profonda”) -> per essere poi composte sulla RAM se ho delle letture oppure poi trasmesse al controller se ho delle scritture.

Mmm...vediamo una riflessione. Considera che l'host, il sistema operativo, non sa che hardware c'è sotto di lui. Quindi opera sempre in astratto con la sua mappatura di LBA. Quindi per fare un esempio molto concreto, se io gli dico di aprirmi un file di testo in Windows e ho un ssd, Windows cerca nella mappatura: le istruzioni per aprire i software, il file di testo, attinge al driver per visualizzarlo e infine me lo propone.
Ognuna di queste operazioni sono Thread...molti thread che windows trasmette all'ssd mediante il pipe DMA.
Attento ora:
1) I thread sono richieste a livello logico (mappatura LBA) non fisica.
2) Il Thread è un entità astratta fatto da una o più richieste (o comandi) I/0

Quando scrivi: l’SSD sempre tramite DMA prende i thread -> l’SSD “risolve” i thread per i fatti suoi
è concettualmente falso

L'host sempre tramite DMA prende i thread -> l'host “risolve” i thread per i fatti suoi

perchè l'elaborazione dell'applicazione ovvero nell'esempio l'apertura del file di testo, è un lavoro tutto a livello logico non fisico (sull'ssd).

DMA su host vede tutte le operazioni da fare (istruzioni per aprire i software, il file di testo, attinge al driver per visualizzarlo) quindi tutti i Thread sotto forma di richieste I/0 (LBA) le organizza per priorità, le accoda e le richiede al Controller dell'ssd, che, poverino, esegue solo (partendo dalla traduzione della mappatura LBA-> blocco fisico).
Ecco il perchè del possibile limite della coda dei comandi (sata 32 vs nvme migliaia). L’unità minima di comunicazione fra host (DMA) e controller è il comando I/O, non il thread che lo origina. Ecco perché si “limita” il numero di comandi pendenti, non i thread. Un protocollo ha più banda passante dell'altro.

Questo invece: "(o in caso di SSD DRAM-less con HMB risolve i thread con un po’ di RAM)" riguarda l'aggiornamento della mappatura o FTL più in generale. Altro discorso.




Comunque, per il numero massimo di QD per thread, TechTarget (https://www.techtarget.com/searchstorage/definition/queue-depth) dice:
[QUOTE]
• I dispositivi Serial ATA o SATA possono supportare una coda di comando con una profondità di coda di 32 comandi.
• I dispositivi Serial-attached SCSI o SAS possono supportare una coda di comando con una profondità di coda di 256 comandi.
• I dispositivi Nonvolatile memory express o NVMe possono supportare un numero massimo di 65.535 code di comando con una profondità di coda fino a 65.536 comandi per coda.

Da qui presumo:
1) TechTarget ha le idee abbastanza confuse;
2) TechTarget ha fatto confusione con i termini per gli SSD NVMe;
3) TechTarget con “coda di comando” non intende i thread ma altro di cui non so. Secondo me sbaglia e la verità è che (penso) ci sia un numero “illimitato”¹ di thread ma non ovviamente di richieste I/O, quindi NVMe può creare massimo 65.536 di richieste I/O per thread, SAS 256 richieste I/O per thread, ecc.
————————————————-
¹: ovviamente non sono illimitati, penso che dipenda dall’applicazione, dalle capacità del controller dell’SSD, dal SO, ecc.

queue depth = richieste I/0

E' giusto, perchè idee confuse?


Il numero di comandi I/O pendenti che l’host può mettere in coda verso il controller sono massimo 32 par AHCI e di miglioia per nvme che inoltra supporta anche comandi di lettura e scrittura contemporanei.


A parte gli errori di battitura :D

Si tratta del principale motivo per cui appena è stato possibile si è passati da sata (ahci) a nvme
Come dice il testo, i I/0 limitati fanno da collo di bottiglia.

"Solid-state drives (SSDs), based on NVMe technology, with its larger queue depth, have faster response times".
Questo non è vero, infatti purtroppo la reattività di un ssd sata e di uno nvme è quasi la stessa. Il PRO è che con nvme "passa" più roba e può essere elaborata parallelamente.




No Liupen, teoricamente nCache, nCache 2.0 e nCache 3.0 son tutte e tre cache SLC statiche, semplicemente perché su tutti i modelli di SSD a cui sono state implementate è così, anche per l’SN750 dove la cache SLC è di ~45GB. nCache 4.0, invece, è una cache SLC ibrida visto l’SN850 (primo modello su cui è stata implementata se ricordo bene). Non so darti molte fonti su quest’ultima semplicemente perché WD non lo dice ma se cerchi “nCache 4.0 hybrid SLC (https://www.google.com/search?q=nCache+4.0+hybrid+SLC&client=safari&sca_esv=7ce7144faa458147&hl=en-gb&sxsrf=AHTn8zpmJL5gEfUJ-QRF6A-D2H6EojE72g%3A1747420974540&ei=LocnaL3iII7vi-gPxdbDuQM&oq=nCache+4.0+hybrid+SLC&gs_lp=EhNtb2JpbGUtZ3dzLXdpei1zZXJwIhVuQ2FjaGUgNC4wIGh5YnJpZCBTTEMyBBAjGCcyBRAhGKABSOM-UK8NWLc7cAl4AZABAJgBcKAB9AmqAQQxMS4zuAEDyAEA-AEBmAIToALBB8ICChAAGLADGNYEGEfCAgUQABjvBcICCBAAGIAEGKIEwgIIEAAYogQYiQXCAgcQIxiwAhgnwgIKECEYoAEYwwQYCsICCBAhGKABGMMEmAMAiAYBkAYIkgcEMTcuMqAHwy-yBwM4LjK4B58HwgcHMC45LjkuMcgHOQ&sclient=mobile-gws-wiz-serp)” su Google vedi che trovi “hybrid SLC” come parole chiave negli articoli (mentre con nCache 3.0 no).

Ok.
nCache 2.0 la conosco bene è statica.
Ma vabbeh! Ormai roba vecchia.
nCache 3.0 e 4.0 non ho approfondito. Tanto tutti i produttori danno nomi diversi allo stesso tipo di cache: anche ora Samsung Turbo Write originale è diventata Turbo Write 2.0 :mc:

@Liupen
17-05-2025, 02:28
Vorrei spiegare il collo di bottiglia, ma alla fine scrivo tanto, troppo e mi sembra poi che il concetto non si capisca:

Esempio di prima, i Thread sono le istruzioni per farmi vedere su schermo un file di testo; Windows/host lancia tutte le istruzioni, DMA le ordina per priorità (esempio dice: prima di andare a cercare il file devo lanciare Microsoft Word). Questo a livello ..."alto"? Davvero infatti il DMA ordina una serie di richieste I/0 (dei vari Thread) in modo che: quando sono finiti tutti gli I/O (LBA sempre eh!) che compongono il "lancio Microsoft Word" posso iniziare a processare le richieste I/0 di "cerco e apro il file richiesto".

Detto questo per dire che per l'host/DMA i thread alla fine sono aria fritta e che il tutto è solo un ordine martellante di richieste (ordinate) I/0, il DMA "sente" se è collegato a SATA o NVME. SATA/AHCI ha dei limiti nel tenere delle code dei comandi quindi il DMA frena. Se il limite di queue depth è raggiunto, le ulteriori richieste restano in sospeso finché il controller non libera risorse.
NVMe ha semplicemente più “linee” di comunicazione e le risorse hardware che il controller può effettivamente gestire in parallelo.

Black (Wooden Law)
17-05-2025, 10:55
Mmm...vediamo una riflessione. Considera che l'host, il sistema operativo, non sa che hardware c'è sotto di lui. Quindi opera sempre in astratto con la sua mappatura di LBA. Quindi per fare un esempio molto concreto, se io gli dico di aprirmi un file di testo in Windows e ho un ssd, Windows cerca nella mappatura: le istruzioni per aprire i software, il file di testo, attinge al driver per visualizzarlo e infine me lo propone.
Ognuna di queste operazioni sono Thread...molti thread che windows trasmette all'ssd mediante il pipe DMA.
Attento ora:
1) I thread sono richieste a livello logico (mappatura LBA) non fisica.
2) Il Thread è un entità astratta fatto da una o più richieste (o comandi) I/0

Quando scrivi: l’SSD sempre tramite DMA prende i thread -> l’SSD “risolve” i thread per i fatti suoi
è concettualmente falso

L'host sempre tramite DMA prende i thread -> l'host “risolve” i thread per i fatti suoi

perchè l'elaborazione dell'applicazione ovvero nell'esempio l'apertura del file di testo, è un lavoro tutto a livello logico non fisico (sull'ssd).

DMA su host vede tutte le operazioni da fare (istruzioni per aprire i software, il file di testo, attinge al driver per visualizzarlo) quindi tutti i Thread sotto forma di richieste I/0 (LBA) le organizza per priorità, le accoda e le richiede al Controller dell'ssd, che, poverino, esegue solo (partendo dalla traduzione della mappatura LBA-> blocco fisico).
Ecco il perchè del possibile limite della coda dei comandi (sata 32 vs nvme migliaia). L’unità minima di comunicazione fra host (DMA) e controller è il comando I/O, non il thread che lo origina. Ecco perché si “limita” il numero di comandi pendenti, non i thread. Un protocollo ha più banda passante dell'altro.

Ok, capisco. Quindi alla fine Windows crea e "organizza" i thread comunicando all'SSD quando sono pronti, e una volta pronti glieli dà da eseguire, giusto?

Comunque, per il numero massimo di QD per thread, TechTarget (https://www.techtarget.com/searchstorage/definition/queue-depth) dice:


queue depth = richieste I/0

E' giusto, perchè idee confuse?

Perché non capisco cosa voglia dire TechTarget con "coda di comando" visto che gli NVMe ne possono supportare migliaia di migliaia mentre i dispositivi SATA e SAS solo una.
Detto questo per dire che per l'host/DMA i thread alla fine sono aria fritta e che il tutto è solo un ordine martellante di richieste (ordinate) I/0, il DMA "sente" se è collegato a SATA o NVME. SATA/AHCI ha dei limiti nel tenere delle code dei comandi quindi il DMA frena. Se il limite di queue depth è raggiunto, le ulteriori richieste restano in sospeso finché il controller non libera risorse.
NVMe ha semplicemente più “linee” di comunicazione e le risorse hardware che il controller può effettivamente gestire in parallelo

Ok, così mi è più chiaro il tuo "L’unità minima di comunicazione fra host (DMA) e controller è il comando I/O". Molto interessante anche questa parte sul perché la QD è più "importante" dei thread.

@Liupen
17-05-2025, 14:48
Ok, capisco. Quindi alla fine Windows crea e "organizza" i thread comunicando all'SSD quando sono pronti, e una volta pronti glieli dà da eseguire, giusto?

Giustissimo.
Diciamo che la parte che interessa l'ssd è quella finale di un processo complesso.
Con un po di logica è possibile però cercare di capire il meccanismo che porta a concetti come I/0, latenza, ECC.

Se vogliamo dare una sequenza:

Comando Host (io che chiedo a Windows di aprire il file di testo PIPPO)
CPU di sistema elabora cosa fare in sequenza per ottenere il risultato
Istruzioni passate a DMA
DMA ha verificato a monte che protocollo usare --> sata/ahci passano "solo" 32 comandi alla volta invece nvme ne può gestire a migliaia.
DMA (in forma di pacchetti richieste I/0 LBA) stabilisce le priorità di queste richieste o comandi I/0 [come vedi tutto internamente all'host]
DMA comunica con il controller dell'ssd e gli invia la lista delle priorità QD da mettere in RAM oppure da scrivere su NAND (lettura e/o scrittura)
Il Controller gestisce i thread (se ce ne più d'uno) a seconda della propria capacità e della larghezza di banda (il famoso collo di bottiglia sata vs nvme) quindi un controller di un ssd nvme può svolgere 2 o più thread assieme ma seguendo il QD creato dal DMA.
Finito ogni thread (sequenza richieste I/0 lettura del blocco all'indirizzo dell'LBA cercato nel nostro esempio e trascritto in RAM di sistema) il controller comunica "eseguito" al DMA che può proseguire con le richieste successive.


Normalmente con un utilizzatore si vedono solo richieste I/0 in fila perchè una è propedeutica ad un altra.
Più richieste host creano gruppi di comandi diversi (thread) ed è li che nvme ha il maggiore vantaggio grazie all'elaborazione di più richieste I/0 di trhead eseguite in parallelo.

Perché non capisco cosa voglia dire TechTarget con "coda di comando" visto che gli NVMe ne possono supportare migliaia di migliaia mentre i dispositivi SATA e SAS solo una.


Ok, così mi è più chiaro il tuo "L’unità minima di comunicazione fra host (DMA) e controller è il comando I/O". Molto interessante anche questa parte sul perché la QD è più "importante" dei thread.

AHCI: una sola queue, profondità massima 32 comandi pendenti.

L’host può avere al massimo fino a 32 comandi pendenti nella sua unica coda.
Se prova a inviarne il 33esimo prima che uno dei primi 32 sia completato, deve aspettare.

E' la differenza tra sata e pcie: sata gestisce un unica coda alla volta (scrivo oppure leggo) e quella coda può avere "solo" 32 richieste I/0
NVMe è un 5G ;) ha la banda larga... può scrivere e leggere in un solo tempo e ognuna di queste migliaia può essere costituita da migliaia di richieste I/0 accodate (il controller di suo non arriverà mai a fornirgliene così tante, ne avrebbe senso perchè le die nand sono un numero esiguo).

@Liupen
17-05-2025, 15:09
Può sorgere la domanda: come mai non è il controller dell'ssd a gestirsi le QD?

Perchè la mente, "l'architetto" è il sistema operativo; la CPU di sistema organizza e muove i dati per realizzare quello che l'host vuole.
C'è un tempo in cui le risorse devono essere organizzate e la sequenza la sà solo l'host che non deve e non può essere in balia di una memoria non volatile che ha caratteristiche varie (hdd PATA, hdd SATA, ssd SATA, ssd NVMe, USB... ecc).
Solo l’host conosce il contesto d’uso complessivo (quali processi, quali file, quali priorità), mentre il controller vede solo singole operazioni di flash.

Il "disco" in generale è solo quindi una rotella dell'ingranaggio, un esecutore che deve essere gestito a monte.

Altro motivo sono i limiti, appunto, delle interfacce varie.
Alcune, come ad esempio quella USB, neanche ai giorni nostri, hanno accesso completo e sono compatibili a tutti i tipi di comandi host (hanno profondità di coda più limitate a causa del protocollo e dell’overhead aggiuntivo).

Black (Wooden Law)
18-05-2025, 00:39
AHCI: una sola queue, profondità massima 32 comandi pendenti.

L’host può avere al massimo fino a 32 comandi pendenti nella sua unica coda.
Se prova a inviarne il 33esimo prima che uno dei primi 32 sia completato, deve aspettare.

E' la differenza tra sata e pcie: sata gestisce un unica coda alla volta (scrivo oppure leggo) e quella coda può avere "solo" 32 richieste I/0
NVMe è un 5G ;) ha la banda larga... può scrivere e leggere in un solo tempo e ognuna di queste migliaia può essere costituita da migliaia di richieste I/0 accodate (il controller di suo non arriverà mai a fornirgliene così tante, ne avrebbe senso perchè le die nand sono un numero esiguo).

Ok perfetto, capito, SATA può gestire solo una coda profonda massimo 32 richieste I/O mentre NVMe 65.000 code profonde massimo 65.000 richieste I/O (circa). Ecco il perché NVMe è nettamente più performante (ma fa ridere il fatto di questa enorme capacità quando in uso normale Windows non sfora QD4).
Può sorgere la domanda: come mai non è il controller dell'ssd a gestirsi le QD?

Perchè la mente, "l'architetto" è il sistema operativo; la CPU di sistema organizza e muove i dati per realizzare quello che l'host vuole.
C'è un tempo in cui le risorse devono essere organizzate e la sequenza la sà solo l'host che non deve e non può essere in balia di una memoria non volatile che ha caratteristiche varie (hdd PATA, hdd SATA, ssd SATA, ssd NVMe, USB... ecc).
Solo l’host conosce il contesto d’uso complessivo (quali processi, quali file, quali priorità), mentre il controller vede solo singole operazioni di flash.

Il "disco" in generale è solo quindi una rotella dell'ingranaggio, un esecutore che deve essere gestito a monte.

Altro motivo sono i limiti, appunto, delle interfacce varie.
Alcune, come ad esempio quella USB, neanche ai giorni nostri, hanno accesso completo e sono compatibili a tutti i tipi di comandi host (hanno profondità di coda più limitate a causa del protocollo e dell’overhead aggiuntivo).

Chiaro, alla fine la mente è il SO/l’host e l’SSD il braccio. L’SSD è intelligente ma solo per le sue operazioni (WL, GC, gestione NAND flash, ecc.), rispetto al resto del contesto come SO e CPU è stupido.

Black (Wooden Law)
19-05-2025, 19:15
Controller da 16 canali, NAND flash eTLC di SK hynix da 176L e un condensatore da 35 V per il PLP... https://www.techpowerup.com/review/phison-pascari-x200e/. :mc:
Mi fa ridere questo:
Mentre non è stato in grado di raggiungere i 3,2 milioni di IOPS [in lettura randomica] da specifica è stato in grado di superare i 3,4 milioni di IOPS a queue depth più alte di QD512.
Ma le performance sono comunque ottime e l'SSD non è assolutamente deludente, anzi, in random batte anche il Memblaze PBlaze 7940 che usa 11 core (!) e le B58R da 6 piani.

NubCake
20-05-2025, 19:03
Vi segnalo che su Ediloca EN870 e Fanxiang S880 (e probabilmente anche Fikwot FN955) sono state cambiate le NAND.

Ho ricevuto oggi da Amazon un EN870, ordinato come nuovo ma si tratta probabilmente di un reso dato che l'heatspreader era piegato e parzialmente sollevato in corrispondenza della NAND, cosa che mi fa pensare che qualcuno lo abbia fatto per leggere le incisioni e poi abbia deciso di restituirlo.

maxio_nvme_fid non riconosce il controller e la NAND, a giudicare da un post che ho trovato sul S880 pare che il controller sia ancora il MAP1602 ma che non venga riconosciuto perché è stata attivata la crittografia del firmware.

La NAND presenta la seguente incisione:
LELM512G6BCB1E LP2510A186 31501 XF12 T9RM09

Cercando su internet non si trova nulla riguardo questa NAND, ma qualcuno altrove ipotizzava potesse essere X3-6070 quindi QLC.

Penso che farò il reso, peccato.

Black (Wooden Law)
20-05-2025, 21:36
Vi segnalo che su Ediloca EN870 e Fanxiang S880 (e probabilmente anche Fikwot FN955) sono state cambiate le NAND.

Ho ricevuto oggi da Amazon un EN870, ordinato come nuovo ma si tratta probabilmente di un reso dato che l'heatspreader era piegato e parzialmente sollevato in corrispondenza della NAND, cosa che mi fa pensare che qualcuno lo abbia fatto per leggere le incisioni e poi abbia deciso di restituirlo.

maxio_nvme_fid non riconosce il controller e la NAND, a giudicare da un post che ho trovato sul S880 pare che il controller sia ancora il MAP1602 ma che non venga riconosciuto perché è stata attivata la crittografia del firmware.

La NAND presenta la seguente incisione:
LELM512G6BCB1E LP2510A186 31501 XF12 T9RM09

Cercando su internet non si trova nulla riguardo questa NAND, ma qualcuno altrove ipotizzava potesse essere X3-6070 quindi QLC.

Penso che farò il reso, peccato.

Ciao, ho visto e risposto al tuo commento su Discord (sono io quello che ti ho detto che il MAP1602 fa crittografia dei dati per il FID) ma è corretto dirlo anche qui: non abbiamo certezze al 100% che sia QLC e quindi vedo insensato fare terrorismo mediatico. Gabriel ha detto che secondo lui il flash è QLC solo perché le NAND flash TLC vengono solitamente riconosciuto dal FID ma il problema è che anche per altri SSD che sono TLC non viene mostrato nulla quindi non la trovo una prova concreta al 100%. Servirebbero altre prove, quindi altri EN870 scoperchiati dai quali si può ottenere un S/N “sensato”.

Io, personalmente, non starei lontano all’EN870 visto che non ci sono prove ma al massimo si può consigliare l’S880 o l’FN955. L’S880 è TLC verificato da recensioni anche recenti, non so il perché tu abbia detto sia EN870 che S880.

NubCake
20-05-2025, 22:41
Ciao Black (Wooden Law), ti ringrazio per l'aiuto su Discord, non cercavo di fare "terrorismo mediatico" ma solamente di informare sullo scorretto (anche se ormai è la prassi per il settore) cambiamento silente della NAND, per evitare che qualcuno, così come ho fatto anche io, acquistasse quei determinati prodotti con la convinzione di ricevere una determinata combinazione di controller + NAND, spinto dalle informazioni trovate in rete ormai non più corrette.

Infatti ho scritto che non si trovava nulla in rete riguardo le nuove NAND, e ho aggiunto che qualcuno aveva ipotizzato che potesse trattarsi di X3-6070, senza riportare nessuna certezza.

Mi dispiace che il tutto sia stato frainteso e se necessario edito il precedente messaggio.

Però ci tengo anche anche a riportare un mio personalissimo pensiero: se alcuni produttori hanno iniziato a limitare la possibilità di riconoscere il controller e le NAND installate attraverso i noti tool, non lo avranno fatto di certo per scopi benevoli.

Io, personalmente, non starei lontano all’EN870 visto che non ci sono prove ma al massimo si può consigliare l’S880 o l’FN955. L’S880 è TLC verificato da recensioni anche recenti, non so il perché tu abbia detto sia EN870 che S880.
Lo ho scritto perché su altri forum ho trovato utenti che hanno ricevuto SSD con NAND con il medesimo codice o codice simile.

Questo (https://forum.ixbt.com/topic.cgi?id=11:50197:71116#71116) è il link che probabilmente hai già visto, dove un utente ha ricevuto un Fanxiang S880 da 2TB con gli stessi moduli NAND dell'Ediloca EN870 1TB da me ricevuto

Continuando la ricerca stasera ho però trovato altri post:
Link 1 (https://forums.overclockers.ru/viewtopic.php?p=18412026#p18412026) - Un utente ha ricevuto a febbraio la versione da 4TB del s880, con moduli nand da 1TB e codice un po' diverso LTLM01TB5BCB5. Ha anche pubblicato lo screen di AIDA64 che dimostra che dovrebbero essere comunque moduli TLC.
Link 2 (https://forums.overclockers.ru/viewtopic.php?f=24&t=570459&p=18444739&hilit=S880#p18444739) - Un altro utente ha ricevuto la versione da 2TB, sempre con gli stessi moduli sconosciuti da 1TB.
Link 3 (https://egg.5ch.net/test/read.cgi/jisaku/1729182890/) - Vari commenti riguardanti sia S880 che EN870. #44 segnala di aver ricevuto EN870 4TB con i moduli LTLM01TB5BCB5 LP2434A170, #57 ha pubblicato le foto del PCB, #90 stessa cosa e sui moduli c'è un adesivo che riporta la dicitura B58R, così come #800, #236 ha ricevuto un S880 con i suddetti moduli da 1TB.
Link 4 (https://egg.5ch.net/test/read.cgi/jisaku/1741057958/) - #593 EN870 2TB con 3dv4-128L(x3-9060) anzi che x3-9070
Link 5 (https://egg.5ch.net/test/read.cgi/jisaku/1729182890/) - #32 EN870 1TB con 3dv4-128L(x3-9060) anzi che x3-9070, #57 EN870 4TB con le NAND B58R già a novembre
Link 6 (https://egg.5ch.net/test/read.cgi/jisaku/1710928856/) - #846 Fikwot FN955 2TB con 3dv4-128L(x3-9060)

A questo punto, i misteriosi moduli da 1TB se ci si può fidare degli adesivi, dovrebbero essere dei Micron B58R? Faranno parte della stessa famiglia anche i 512GB?

Grazie ancora per l'aiuto.

Edit: continuo ad aggiungere link alle fonti edittando questo post
Edit2: Ipotesi mia, probabilmente la NAND da 512GB non è una Micron B58R, avendo footprint diversi...

Black (Wooden Law)
20-05-2025, 23:48
Non ti preoccupare NubCake, non devi assolutamente editare alcun messaggio anche perché non sono qui per fare il dittatore, semplicemente ho trovato inadatto il tuo “Vi segnalo che su Ediloca EN870 e Fanxiang S880 […] sono state cambiate le NAND” su una base speculativa e fuorviante di Gabriel Ferraz. Provo tanta stima verso quel ragazzo anche perché è diventato recensore e creatore del DB di TPU in poco tempo, però anche lui stesso a volte sbaglia e dire che il tuo ex-EN870 usi NAND flash YMTC X3-6070 solo perché i dati sono criptati lo trovo abbastanza stupido o perlomeno incompleto. Magari ha ragione eh (anche se le fonti che mi hai mandato non provano questo), ma non basta per esserne sicuri al 100%.
Però ci tengo anche anche a riportare un mio personalissimo pensiero: se alcuni produttori hanno iniziato a limitare la possibilità di riconoscere il controller e le NAND installate attraverso i noti tool, non lo avranno fatto di certo per scopi benevoli.

Ragionamento legittimo, il fatto è che ci sono anche produttori “affidabili” come Silicon Power e Lexar che usa la crittografia del MAP1602 per il FID. Questa disponibilità di criptare i dati sembra essere una feature del MAP1602 (che non son sicuro abbiano anche gli altri controller) quindi non varia dal produttore.

Questo è il link che probabilmente hai già visto, dove un utente ha ricevuto un Fanxiang S880 da 2TB con gli stessi moduli NAND dell'Ediloca EN870 1TB da me ricevuto

Continuando la ricerca stasera ho però trovato altri post:
Link 1 - Un utente ha ricevuto a febbraio la versione da 4TB del s880, con moduli nand da 1TB e codice un po' diverso LTLM01TB5BCB5. Ha anche pubblicato lo screen di AIDA64 che dimostra che dovrebbero essere comunque moduli TLC.
Link 2 - Un altro utente ha ricevuto la versione da 2TB, sempre con gli stessi moduli sconosciuti da 1TB.
Link 3 - Vari commenti riguardanti sia S880 che EN870. #44 segnala di aver ricevuto EN870 4TB con i moduli LTLM01TB5BCB5 LP2434A170, #57 ha pubblicato le foto del PCB, #90 stessa cosa e sui moduli c'è un adesivo che riporta la dicitura B58R, così come #800, #236 ha ricevuto un S880 con i suddetti moduli da 1TB.

Disamina molto interessante NubCake, ti ringrazio delle fonti e delle informazioni generali, sono molto preziose. A quanto pare non c’è traccia di NAND flash QLC anche se avrei preferito vedere delle NAND flash EET1A al posto delle B58R per la questione binning.
A questo punto, i misteriosi moduli da 1TB se ci si può fidare degli adesivi, dovrebbero essere dei Micron B58R? Faranno parte della stessa famiglia anche i 512GB?

Impossibile da dire purtroppo ma sui tagli così piccoli sicuramente le NAND flash sono TLC, quelle QLC vengono adottate in tagli più grandi come 4TB (vedere il Patriot Viper VP4300 Lite (https://www.techpowerup.com/ssd-specs/patriot-viper-vp4300-lite-4-tb.d1581) per esempio)

sbaffo
21-05-2025, 10:58
che mi dite dell'Orico D10 ? qui dice TLC:
https://www.amazon.it/dp/B0DLG1S1Q3/?tag=toms-scontitech-21&ascsubtag=12161_coupon&linkCode=ogi&th=1
ma su TPU quel modello non c'è, e il prezzo sembra troppo buono per un 2TB (95eu)

Black (Wooden Law)
21-05-2025, 11:58
che mi dite dell'Orico D10 ? qui dice TLC:
https://www.amazon.it/dp/B0DLG1S1Q3/?tag=toms-scontitech-21&ascsubtag=12161_coupon&linkCode=ogi&th=1
ma su TPU quel modello non c'è, e il prezzo sembra troppo buono per un 2TB (95eu)

In Giappone arriva con due versioni: la prima (https://pc.asobu.co.jp/orico-d10-1tb/) ha un controller indecente (SM2263XT) e delle NAND flash SK hynix V7 (176L) di scarto, la seconda (https://pc.asobu.co.jp/orico-d10-1tb/) ha un controller decente (MAP1202) e delle NAND flash SpecTek B58R di scarto (addirittura ci sono delle “cancellazioni” del S/N sul package) mentre in Russia (https://www.ixbt.com/live/data/obzor-m2-nvme-ssd-nakopitelya-orico-d10-s-17-13-gb-s-chtenie-zapis-za-menee-chem-20.html#pid=4) il modello da 256GB arriva con un controller PCIe 3.0 x2 mai sentito (SM2261XT) e delle NAND flash con sopra un S/N totalmente sconosciuto e non identificabile (anche se dalle performance sembrano essere chiaramente delle TLC).

Direi che come SSD fa piuttosto schifo ed è assolutamente da evitare, ma il colpo di grazie ce lo dà la prima recensione giapponese: il package dell’SSD dice “SM2263ENG” non “SM2263XT”, anche perché la versione “ENG” ha il supporto della DRAM, quindi perché il FID lo riconosce come “SM2263XT”? Semplice, è una falsa incisione e la prova ce lo dà il fatto che l’SSD sia DRAM-less nonostante a bordo abbia un controller che dovrebbe supportare la DRAM.

NubCake
21-05-2025, 12:03
che mi dite dell'Orico D10 ? qui dice TLC:
https://www.amazon.it/dp/B0DLG1S1Q3/?tag=toms-scontitech-21&ascsubtag=12161_coupon&linkCode=ogi&th=1
ma su TPU quel modello non c'è, e il prezzo sembra troppo buono per un 2TB (95eu)

Lo avevo preso in considerazione anche io poi lo ho scartato.

Cerca la parola QLC tra le recensioni su Amazon, e ti mostrerà diverse recensioni della variante da 1TB in cui gli acquirenti su Amazon.jp si lamentano del fatto che le NAND sono state sostituite da QLC Intel nonostante il modello sia venduto dichiarando espressamente l'utilizzo di TLC.

Potrebbe essere solo una questione regionale, ma considerato che ORICO non si pone problemi ad effettuare cambiamenti neanche nei modelli di "fascia alta", se acquisti fallo con la consapevolezza che il prodotto potrebbe non rispettare le caratteristiche dichiarate e verifica appena ti arriva.

Black (Wooden Law)
21-05-2025, 12:57
Cerca la parola QLC tra le recensioni su Amazon, e ti mostrerà diverse recensioni della variante da 1TB in cui gli acquirenti su Amazon.jp si lamentano del fatto che le NAND sono state sostituite da QLC Intel nonostante il modello sia venduto dichiarando espressamente l'utilizzo di TLC.

Che poi la cosa divertente è che non sono manco NAND flash QLC native ma sono NAND flash QLC emulate dalle Intel 192L PLC, quindi sono delle PLC in pQLC. Performance e durata dovrebbero essere pari alle QLC native ma fa comunque ribrezzo.

@Liupen
21-05-2025, 15:17
Che poi la cosa divertente è che non sono manco NAND flash QLC native ma sono NAND flash QLC emulate dalle Intel 192L PLC, quindi sono delle PLC in pQLC. Performance e durata dovrebbero essere pari alle QLC native ma fa comunque ribrezzo.

E' antieconomico fare questo più che altro.

Black (Wooden Law)
21-05-2025, 23:20
E' antieconomico fare questo più che altro.

Dici questo perché non ha senso prendere delle NAND flash PLC da far operare per tutta la loro vita in pQLC o per altro?

@Liupen
22-05-2025, 10:43
Dici questo perché non ha senso prendere delle NAND flash PLC da far operare per tutta la loro vita in pQLC o per altro?

Anche, ma non solo; sono celle ancora costose perchè la tecnologia di produzione unica ha richiesto un investimento iniziale ingente (floating gate Solidigm di nuova generazione). Questo costo di know-out di produzione sarebbe ammortizzato dall'uso in PLC (cioè con il 20% di densità in più per bit) e dalla grande quantità di forniture.
Manca l'una e l'altra.
Usandolo QLC significa perdere denaro.
Il problema principale delle PCL, avevo letto, stà essenzialmente che i 32 livelli di tensione richiedono ECC importante ed un calo della velocità di lettura anche, e/o un rischio ancora troppo elevato di perdere dati. QLC o pQLC rimane in "confort zone".

Black (Wooden Law)
22-05-2025, 11:05
Anche, ma non solo; sono celle ancora costose perchè la tecnologia di produzione unica ha richiesto un investimento iniziale ingente (floating gate Solidigm di nuova generazione). Questo costo di know-out di produzione sarebbe ammortizzato dall'uso in PLC (cioè con il 20% di densità in più per bit) e dalla grande quantità di forniture.
Manca l'una e l'altra.
Usandolo QLC significa perdere denaro.

Capisco, quindi dici che non c'è profitto a comprare delle PLC in pQLC (e ha senso come cosa, a 'sto punto prendi delle QLC native e basta, proprio come stanno facendo tutti i produttori di SSD).
Il problema principale delle PCL, avevo letto, stà essenzialmente che i 32 livelli di tensione richiedono ECC importante ed un calo della velocità di lettura anche, e/o un rischio ancora troppo elevato di perdere dati. QLC o pQLC rimane in "confort zone".

Beh ma questa è sicuramente la solita storiella di quando si parla di NAND flash con più bit per cella e più stati di tensione di soglia. Le NAND flash PLC non stanno andando nel mercato consumer (tranne in qualche sporadico SSD cinese) perché Solidigm è l'unico attuale venditore e ha deciso di abbandonare il segmento consumer concentrandosi su quello enterprise. Poi, il motivo per il quale operino in pQLC anziché PLC penso sia il fatto che comunque ci sono dei vantaggi in pQLC, come li ebbe l'850 PRO con le NAND flash TLC ma operanti in pMLC. Mettici anche tutto il terrorismo mediatico che si fa con le NAND flash QLC... Non so, non mi viene da pensare che queste NAND flash esprimano grossi problemi di ritenzione dei dati, anche perché non sono stati notati anche dopo 1.000 PEC nel paper di Solidigm.

frafelix
22-05-2025, 11:41
Samsung poteva fare economie di scala visto che le nand se le produce, quindi in quel caso poteva essere che per qualche motivo gli conveniva

@Liupen
22-05-2025, 13:42
Solidigm è SK Hynix a tutti gli effetti... diciamo la branca degli ssd ad alta capienza. Orientati al data center core e edge (banca dati AI, ecc).

Non solo, è la porta che apre gli USA (il grosso del mercato occidentale, noi europei compresi, visto che obbligatoriamente ne adottiamo i limiti di acquisto e vendita). Una "porta" fatta di fabbriche delocalizzate in america, facendo finta che SK Hynix è coreana e Solidigm, nascendo dalle ceneri di Intel, è filo-"occidentale".

Solidigm non deve comprare celle PLC da utilizzare in pQLC perchè si fà da sola queste celle e si fà da sola gli ssd (i controller magari sono anche acquistati ma anche no).

Essendo tra i pochi che producono celle PLC, ben venga, ma si tratta di usare queste celle in modo "strano". Non ci sono vantaggi a emulare le celle PLC in QLC, solo svantaggi e sono svantaggi economici di produzione. Se sono usate in quel modo, a logica direi che i motivi possono essere due: la tecnologia ECC ancora acerba oppure (se questo non è vero) la durata (ovvio) e le prestazioni, non ancora soddisfacenti.

Se un modello Samsung 850 PRO ha usato celle TLC emulate lo avrà fatto per un altro motivo... se le MLC non vengono più prodotte ed ho la produzione dell'ssd ancora attiva, uso un modo di raggiungere ugualmente l'obbiettivo, no?! Un po come sempre Samsung che cambia il controller del 970 evo Plus perchè c'era carenza di quel modello di controller uscito fuori produzione e un eccedenza dei controller del 980.

Motivi proprio diversi, ma a parte questo, penso che hai travisato, non mi fare così superficiale da dar credito al terrorismo QLC! ;)
Ho scritto: Il problema principale delle PCL, avevo letto, stà essenzialmente che i 32 livelli di tensione richiedono ECC importante ed un calo della velocità di lettura anche, e/o un rischio ancora troppo elevato di perdere dati. QLC o pQLC rimane in "confort zone".

Quindi 32 stati di carica non sono 16, e si, richiedono un algoritmo ECC migliore e che rallenta le prestazioni (che peso ha questo nel discorso pSLC in un ssd per grandi movimento di dati, lo ignoro).

Il "rischio" di cui parlo e l'uso in "confort zone" come l'ho definito, è legato non alla ritenzione dati ma all'usura.

Dire che le QLC hanno minore ritenzione dei dati rispetto alle TLC o le PLC rispetto alle QLC direi che è un dato oggettivo.
Un ssd che si "consuma" prima, perde i dati prima. Incontestabile.

Quindi se acquisto per 3.500 $ più o meno un Solidigm da 30 GB in QLC che mi dura 5 anni o un Solidigm da 30 GB in PLC che mi dura meno di 4, una certa differenza la fà, no?.

Black (Wooden Law)
22-05-2025, 14:30
Essendo tra i pochi che producono celle PLC, ben venga, ma si tratta di usare queste celle in modo "strano". Non ci sono vantaggi a emulare le celle PLC in QLC, solo svantaggi e sono svantaggi economici di produzione. Se sono usate in quel modo, a logica direi che i motivi possono essere due: la tecnologia ECC ancora acerba oppure (se questo non è vero) la durata (ovvio) e le prestazioni, non ancora soddisfacenti.

Anche a me viene da pensare questo seppure il paper dica che le 192L PLC reggano 1.000 PEC, però ci sono comunque dei vantaggi a far funzionare le PLC in pQLC, come ci sono dei vantaggi a far funzionare le TLC in pMLC, ecc. Mi sembra ovvio che questi vantaggi siano a livello di performance e durata; tu imponi alle tue celle NAND flash di usare meno livelli di tensione di soglia, imponi a queste NAND flash anche di programmare meno blocchi di quanti ne ha a disposizione (infatti la capacità diminuisce), ci sono per forza dei risultati migliori sia dal punto di vista della durata che delle performance.
Se un modello Samsung 850 PRO ha usato celle TLC emulate lo avrà fatto per un altro motivo... se le MLC non vengono più prodotte ed ho la produzione dell'ssd ancora attiva, uso un modo di raggiungere ugualmente l'obbiettivo, no?! Un po come sempre Samsung che cambia il controller del 970 evo Plus perchè c'era carenza di quel modello di controller uscito fuori produzione e un eccedenza dei controller del 980.

Ma l'850 PRO è nato con le NAND flash pMLC, non TLC. Quando Samsung ha annunciato l'850 PRO la produzione delle NAND flash MLC mica si era fermata, anche perché è poi venuto l'860 PRO e il 970 PRO.
Motivi proprio diversi, ma a parte questo, penso che hai travisato, non mi fare così superficiale da dar credito al terrorismo QLC! ;)
Ho scritto: Il problema principale delle PCL, avevo letto, stà essenzialmente che i 32 livelli di tensione richiedono ECC importante ed un calo della velocità di lettura anche, e/o un rischio ancora troppo elevato di perdere dati. QLC o pQLC rimane in "confort zone".

Quindi 32 stati di carica non sono 16, e si, richiedono un algoritmo ECC migliore e che rallenta le prestazioni (che peso ha questo nel discorso pSLC in un ssd per grandi movimento di dati, lo ignoro).

Il "rischio" di cui parlo e l'uso in "confort zone" come l'ho definito, è legato non alla ritenzione dati ma all'usura.

Ok, allora ho frainteso io "perdere i dati" con il data retention. Se nella pratica sono veramente 1.000 PEC come da specifica, non penso che possano essere categorizzate così poco durature rispetto alle QLC (che anche loro fanno di media 1.000 PEC massimo 1.500 PEC). Bisognerebbe vedere anche se solitamente la valutazione dei cicli di programmazione/cancellazione è minima, nel senso che alla fine le NAND flash reggono anche un quantitativo maggior di cicli.

sbaffo
22-05-2025, 15:12
In Giappone arriva con due versioni: la prima (https://pc.asobu.co.jp/orico-d10-1tb/) ha un controller indecente (SM2263XT) e delle NAND flash SK hynix V7 (176L) di scarto, la seconda (https://pc.asobu.co.jp/orico-d10-1tb/) ha un controller decente (MAP1202) e delle NAND flash SpecTek B58R di scarto (addirittura ci sono delle “cancellazioni” del S/N sul package) mentre in Russia (https://www.ixbt.com/live/data/obzor-m2-nvme-ssd-nakopitelya-orico-d10-s-17-13-gb-s-chtenie-zapis-za-menee-chem-20.html#pid=4) il modello da 256GB arriva con un controller PCIe 3.0 x2 mai sentito (SM2261XT) e delle NAND flash con sopra un S/N totalmente sconosciuto e non identificabile (anche se dalle performance sembrano essere chiaramente delle TLC).

Direi che come SSD fa piuttosto schifo ed è assolutamente da evitare, ma il colpo di grazie ce lo dà la prima recensione giapponese: il package dell’SSD dice “SM2263ENG” non “SM2263XT”, anche perché la versione “ENG” ha il supporto della DRAM, quindi perché il FID lo riconosce come “SM2263XT”? Semplice, è una falsa incisione e la prova ce lo dà il fatto che l’SSD sia DRAM-less nonostante a bordo abbia un controller che dovrebbe supportare la DRAM.

Lo avevo preso in considerazione anche io poi lo ho scartato.

Cerca la parola QLC tra le recensioni su Amazon, e ti mostrerà diverse recensioni della variante da 1TB in cui gli acquirenti su Amazon.jp si lamentano del fatto che le NAND sono state sostituite da QLC Intel nonostante il modello sia venduto dichiarando espressamente l'utilizzo di TLC.

Potrebbe essere solo una questione regionale, ma considerato che ORICO non si pone problemi ad effettuare cambiamenti neanche nei modelli di "fascia alta", se acquisti fallo con la consapevolezza che il prodotto potrebbe non rispettare le caratteristiche dichiarate e verifica appena ti arriva.
Grazie, insomma la solita cinesata tremenda. Ricordavo che Orico faceva di buoni adattatori, li credevo seri, invece...
Tra le immagini di Amz spicca "Flash Nand TLC Selezionato" :asd: e "sicuro, affidabile, durevole". Si, hanno selezionato accuratamente gli scarti. :nono:

Il P31 2TB che presi a settembre scorso per mio nipote a 125€ sembra ancora un affare imbattuto.

Black (Wooden Law)
22-05-2025, 15:19
Grazie, insomma la solita cinesata tremenda. Ricordavo che Orico faceva di buoni adattatori, li credevo seri, invece...
Tra le immagini di Amz spicca "Flash Nand TLC Selezionato" :asd: e "sicuro, affidabile, durevole". Si, hanno selezionato accuratamente gli scarti. :nono:

Guai ne fa Orico visto che mette NAND flash QLC in SSD detti TLC (IG740-Pro), però penso che il mercato asiatico sia diverso da quello europeo e quindi ci sia l la possibilità di avere NAND flash ben peggiori delle nostre.

@Liupen
22-05-2025, 18:24
Ma l'850 PRO è nato con le NAND flash pMLC, non TLC. Quando Samsung ha annunciato l'850 PRO la produzione delle NAND flash MLC mica si era fermata, anche perché è poi venuto l'860 PRO e il 970 PRO.


Questa non l'ho mai saputa, sei sicuro.
Non mi ricordavo che il Samsung 850 PRO fosse il primo sata con celle 3D ed ok, ma neanche una recensione di queste riporta che le V-nand 32 livelli fosse una falsa MLC (2bit).

Black (Wooden Law)
22-05-2025, 18:55
Questa non l'ho mai saputa, sei sicuro.
Non mi ricordavo che il Samsung 850 PRO fosse il primo sata con celle 3D ed ok, ma neanche una recensione di queste riporta che le V-nand 32 livelli fosse una falsa MLC (2bit).

Molto semplicemente, Liupen, non sono mai esistite le Samsung 32L MLC. Le Samsung 32L (V2) sono nativamente TLC come riportato dovunque nell'ISSCC (https://borecraft.com/PDF/Technical%20Digests/128Gb_3b_VNAND.pdf). Samsung è stata furba e ha detto che le NAND flash sono nativamente MLC perché non c'è differenza¹ tra pMLC e MLC e così facendo nessuno si è accorto (o perlomeno non se ne sono resi conto i recensori che ai tempi non c'era tutta la "libertà" di oggi con gli ISSCC).

La stessa cosa la fa ora Solidigm con il D7-P5510 (https://www.solidigm.com/products/data-center/d7/p5510.html) che dice essere un "144L TLC" quando le uniche 144L sul mercato sono QLC (e sono ovviamente di Intel), lo fa con il D7-P5810 (https://www.solidigm.com/products/data-center/d7/p5810.html) dicendo che è un "144-layer SLC" quando in realtà le NAND flash sono QLC e lo fa sia con il D5-P5430 (https://www.solidigm.com/products/data-center/d5/p5430.html#configurator) che con il D5-P5336 (https://www.solidigm.com/products/data-center/d5/p5336.html#configurator) dicendo che le NAND flash sono "192L QLC" quando sono in realtà delle PLC in pQLC.
--------------------------------------------------------------------------------------
¹: "non c'è differenza" virgola, comunque le V2 hanno nativamente 16kB di pagine mentre le MLC 8kB. È come dire che un SSD con NAND flash SLC è lo stesso di un SSD con NAND flash TLC in pSLC: non lo sono, comunque quello con NAND flash SLC sarà migliore visto che le pagine sono molto più piccole (2-4kB vs. 16kB), i transistor contengono più carica e le performance in termini di tR e tPROG sono migliori.

frafelix
23-05-2025, 10:30
Non era il 950 pro il primo con le nand 3d?

Black (Wooden Law)
23-05-2025, 11:14
Non era il 950 pro il primo con le nand 3d?

No, il primo in assoluto è l'850 PRO rilasciato a luglio 2014. Ad agosto 2013 è stato poi rilasciato l'840 EVO che è stato il primo SSD Samsung ad esser con NAND flash TLC (ma planari) mentre il 950 PRO è stato il primo modello NVMe di Samsung e aveva anche le Samsung V2 da 32L.

Black (Wooden Law)
23-05-2025, 23:19
Dal 20 al 23 marzo si è tenuto il Computex 2025 in Taiwan, una "fiera" dei computer. Le novità nello storage sono molto interessanti ma essendoci tanta carne sul fuoco va categorizzato il tutto per bene :sofico:

Silicon Motion (controller)
Silicon Motion ha presentato due nuovi controller: il primo è DRAM-less ed è pensato per gli SSD PCIe 5.0 mentre il secondo è pensato per USB4. Il primo si chiama SM2504XT ed è costruito sui 6 nm di TSMC (gli stessi dell'SM2508 DRAM-based di fascia alta), ha 4 canali da 3.600 MT/s e offre delle performance sequenziali di 11-11,5 GB/s e delle performance randomiche da 1,7-2 milioni di IOPS. All'apparenza il controller non ha un IHS in nichel come altri controller tipo l'SM2508, il MAP1806, ecc. ma visto il nodo, le performance e i 4 canali ci si può aspettare basse temperature.

Il secondo controller, invece, per USB4 è l'SM2324. Esso fornisce performance fino a 4.000 MB/s, supporta sia le NAND flash TLC che quelle QLC e supporta capacità fino a 32TB.
Phison (controller)
Anche Phison non si è trattenuta mostrando due nuovi controller di cui uno molto interessante. Uno lo conoscevamo già ed è in progetto da tanto tempo ed è il Phison E28 (PCIe 5.0) mentre il secondo è un prototipo per PCIe 6.0 e si chiama PT1601.

Del Phison E28 conosciamo le caratteristiche fin dall'annuncio: 8 canali da 4.200 MT/s (ancora non sfruttabili dalle attuali NAND flash), 32 CE totali ed è lavorato sui 6 nm di TSMC. Sulla carta, avendo come performance 14,9 GB/s in sequenziale e 3 milioni di IOPS (l'SN8100 che è attualmente il PCIe 5.0 più veloce sul mercato non supera i 2,3 milioni di IOPS) è il miglior controller mai visto ma bisogna vedere con le attuali NAND flash come si adegua, se effettivamente tocca i 3 milioni di IOPS.

Per quanto concerne il PT1601, invece, non si sa assolutamente niente, non c'è neanche un test di CDM che solitamente fanno sempre i produttori quindi magari non è manco funzionante (anche se dubito). PCIe 6.0 x4 dovrebbe offrire poco più di 30 GB/s. Sicuramente questo prototipo mette in mostra come Phison voglia partire in buona posizione per la prossima generazione di SSD.

Realtek (controller)
Un nome probabilmente mai sentito per i controller PCIe 4.0 ma sicuramente conosciuto per gli SSD SATA e PCIe 3.0. Diciamo che Realtek non è mai stata tutto sto granché con gli SSD NVMe PCIe 3.0 (ma neanche per i SATA in realtà), però a quanto pare vuole anche lei accaparrarsi una fetta di mercato con l'RTS5781, un controller per SSD PCIe 5.0 DRAM-less da 4 canali (3.600 MT/s) e che offre performance fino a 10 GB/s da fascia bassa. La scelta di avere un controller così poco performante può essere utile per alcuni SSD veramente "scarsi" ma bisogna vedere se per i produttori conviene un controller del genere anziché l'E31T che perlomeno fa 11 GB/s.

Realtek ha anche parlato dell'RM1220, un controller per USB 3.2 Gen2x2 comparabile all'SM2322 (https://www.siliconmotion.com/download/DWjr/a/SM2322_PB_EN.pdf) e che arriva fino a 2,1-2,0 GB/s.
Kioxia
Kioxia ha finalmente annunciato il suo primo SSD PCIe 5.0: l'Exceria Pro G2. Essendo ancora sotto sviluppo (come la sua controparte enterprise CM9) non si sa mezza informazione, giusto, giusto che ha una velocità superiore di 14 GB/s. Da una brand del genere non ci si può che aspettare altro che controller Phison e NAND flash Kioxia BiCS8, anche se come già sappiamo Phison non sta andando molto bene in questa generazione (motivo per il quale l'E28 deve rivoluzionare tutto altrimenti per loro è andata).

Lexar
Lexar a questo Computex ha presentato due SSD PCIe 5.0: l'NM1090 Pro e l'NM990. L'NM1090 Pro c'è sul mercato da un po' di tempo e sappiamo che tra poco verrà recensito da TPU (https://imgur.com/a/CjyeDsb) mentre dell'NM990 non sappiamo nulla se non che le performance sono 14 GB/s in lettura e 11 GB/s in scrittura. L'NM1090 Pro, per inciso, ha un SM2508 come controller (quindi DRAM-based) e delle NAND flash YMTC ma di cui non si sa il modello, se 232L o 267L.

Netac
Netac ha presentato l'SSD PCIe 5.0 NVI50MK, un SSD con heatsink e performance da 14 GB/s in lettura e 11 GB/s in scrittura. Non si sa né il controller né le NAND flash ma sappiamo che ha la DRAM. Da queste informazioni non posso far altro che assumere che il controller sia l'E26 anche se sorpassato dalla concorrenza.

Patriot
Tre nuovi SSD da Patriot (tutti PCIe 5.0)
- PV593: performance di picco da 14 GB/s e 13 GB/s (rispettivamente lettura e scrittura), 2 milioni di IOPS, DRAM e come controller l'SM2508;
- PV563: performance di picco da 14 GB/s e 11,5 GB/s (rispettivamente lettura e scrittura), DRAM-less con controller MAP1806 (anche se il MAP1806 arriva fino a 14 GB/s per la scrittura);
- PV573: futuro SSD che si dovrebbe mettere in mezzo ai due precedenti.
Silicon Power
Silicon Power ha presentato due SSD:
- XS90: controller da 6 nm (probabilmente SM2508 anche se TPU dice erroneamente MaxioTech (https://imgur.com/a/ZvQ7FhA)) e performance di picco da 14 GB/s;
- US85: performance da 10,3 GB/s in lettura 8,6 GB/s. Così basse che l'unico controller ad avere queste performance è... l'RTS5781. :D

Nello stand SP c'era anche la nuova linea Endura ed Endura Nas.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Facendo la resa dei conti direi che le notizie più interessanti sono sicuramente l'SM2504XT, il Lexar NM990, i due SSD Silicon Power e anche gli SSD Patriot. Un extra è questa (https://imgur.com/a/vKjgCJS) "mappa" interessante degli SSD PCIe 5.0 che usano controller Silicon Motion. Da notare Ediloca, Fanxiang e Fikwot anche se Fanxiang ha già un modello PCIe 5.0 con controller E26 e NAND flash B58R da sempre (S900 Pro (https://www.techpowerup.com/ssd-specs/fanxiang-s900-pro-1-tb.d1774)).

P.S.: ci sarebbe altri marchi di SSD da includere come Teamgroup, Transcend e Biwin (anche se Biwin ha presentato un SSD già recensito e sul mercato) ma non essendo presenti nel mercato europeo li ho esclusi apposta.

Gundam1973
24-05-2025, 00:40
Domanda per voi esperti del settore.
Ho la config in firma e per ora, per il mio utilizzo, sono ancora soddisfatto e credo mi durera almeno un annetto ancora....forse inframezzato da una 9070xt se escono i waterblock e mi sale la scimmia. Ma veniamo a noi, la mobo ha 2 slot nvme gen4 occupati da 2 crucial p5+ uno da 512 di boot e uno da 1tb per storage e giochi. Ora vorrei prendere un altro ssd da 1 o 2 gb, piu da due che da uno, per sostituire il 512 e qui sorgono le domande:
1) Vorrei rimanere su crucial ma non so se prendere un gen5 (T700) o rimanere su un gen4 (T500) e usarlo ovviamente come gen4 in attesa un domani di cambiare piatta.
2) Quindi la seconda domanda è come si comporta un ipotetico gen5 in uno slot gen4? Satura la banda? Si livella all'altro P5+ da 1tb nell'altro slot?
3)Vorrei da voi un analisi consiglio per i tre ssd come qualità/tipologia:
a) P5+ Che sembra fuori produzione e sostituito dal T500,credo. Ma si trovano ancora in giro.
b) T500 "che te lo tirano dietro"
c) T700 per il Gen5.

Fermo restando che lato prestazioni sarei gia soddisfatto mi servirebbe giusto piu spazio ma gia che ci sono....

Fatevi sotto!:D :D

Black (Wooden Law)
24-05-2025, 08:22
1) Vorrei rimanere su crucial ma non so se prendere un gen5 (T700) o rimanere su un gen4 (T500) e usarlo ovviamente come gen4 in attesa un domani di cambiare piatta.

Ti consiglio di andare assolutamente con un SSD PCIe 4.0 visto che dici che le performance del P5 Plus ti bastano ma non ti consiglio il T500 che non è né il migliore come performance né il migliore come rapporto qualità-prezzo piuttosto con il P41 (https://www.amazon.it/SK-Platinum-interno-7-000MB-compatto/dp/B09QVD9V7R/ref=mp_s_a_1_3?crid=5FK5KJE5UE9E&dib=eyJ2IjoiMSJ9.FmxBWqceLOdQf0W0AFl6HLKZU32y_b5UD4-YvMz3LmHxcKQmiRu1amU-yqcNhqVXwLq9pBozFf_nqzMW1KCj5b6ofGp_SQ6GSO7nvGpSZSefncstdyH0eqkwEaY5VQDo0GvsP1ljc2hBdXFSNPEyhryUzJRgPqmLF9UrDdTHI-7CLejx_vZJkB9tpJYMSndGvchg8vXmiqrhitgP4s8p5w.EVQ3buc6l70AioPkInde-_a8YsYYzX5t831HPzvqfAE&dib_tag=se&keywords=Sk+hynix+p41&qid=1748067147&sprefix=sk+hynix+p%2Caps%2C479&sr=8-3&ufe=app_do%3Aamzn1.fos.9d4f9b77-768c-4a4e-94ad-33674c20ab35) che reputo sii essere il miglior PCIe 4.0 in commercio (o comunque tra i migliori sicuramente).
2) Quindi la seconda domanda è come si comporta un ipotetico gen5 in uno slot gen4? Satura la banda? Si livella all'altro P5+ da 1tb nell'altro slot?

Satura l’intera banda PCIe 4.0 (~7,5 GB/s) e si comporta assolutamente meglio del P5 Plus che in lettura non supera i 6,6 GB/s e in scrittura i 5 GB/s. Il P5 Plus - seppure non faccia schifo - è stata una delusione fin da subito secondo me, soprattutto tenendo conto del prezzo.
3)Vorrei da voi un analisi consiglio per i tre ssd come qualità/tipologia:
a) P5+ Che sembra fuori produzione e sostituito dal T500,credo. Ma si trovano ancora in giro.
b) T500 "che te lo tirano dietro"
c) T700 per il Gen5.

Come già consigliato sopra, P41 e nessuno di questi. Il P5 Plus è EOL come dici tu e anche se non lo fosse non lo consiglierei manco a pagamento, il T500 ha problemi con la cache SLC (anche se potresti non notarli) e nel taglio da 2TB ha un costo spropositato (15 € in più del P41) mentre il T700 non ha senso visto il T705 che costa qualche euro in più (sempre 2TB).

makka
24-05-2025, 10:20
Il P41 dopo l'aggiornamento del firmware mantiene le prestazioni in scrittura e non "scende" come prima.
Sono passati 2 mesi e le prestazioni rimangono costanti.

In rete però ho letto che qualcuno rileva ancora problemi,
nel mio caso è stato risolutivo.

Gundam1973
24-05-2025, 11:15
Grazie delle risposte!

Si ho scritto T700 ma intendevo T705 mea culpa era notte fonda.

Dunque a scanso di equivoci a me la differenza tra 5000 o 7000mbs influisce il giusto come influisce poco anche una differenza di 15€ sull'acquisto mentre mi fa una grande differenza rimanere con "ecosistema" unico e quindi un unico sw di gestione. E' una mia fisima...non sopporto piu avere 2000 sw diversi.

Ricapitolando, rimanendo in casa Crucial, mi bocci sia il p5+ che il T500 rimarrebbe solo il T705 andando quindi su gen5 o anche su gen4 ti risultano modelli decenti? Ho visto che son spuntati fuori anche i P310 che piu o meno sembrerebbero equivalenti i p5+ in quanto a prestazioni di targa.

frafelix
24-05-2025, 11:49
Non è che devi per forza installare il software del produttore, io non lo faccio…

@Liupen
24-05-2025, 11:50
Molto semplicemente, Liupen, non sono mai esistite le Samsung 32L MLC. Le Samsung 32L (V2) sono nativamente TLC come riportato dovunque nell'ISSCC (https://borecraft.com/PDF/Technical%20Digests/128Gb_3b_VNAND.pdf). Samsung è stata furba e ha detto che le NAND flash sono nativamente MLC perché non c'è differenza¹ tra pMLC e MLC e così facendo nessuno si è accorto (o perlomeno non se ne sono resi conto i recensori che ai tempi non c'era tutta la "libertà" di oggi con gli ISSCC).


--------------------------------------------------------------------------------------
¹: "non c'è differenza" virgola, comunque le V2 hanno nativamente 16kB di pagine mentre le MLC 8kB. È come dire che un SSD con NAND flash SLC è lo stesso di un SSD con NAND flash TLC in pSLC: non lo sono, comunque quello con NAND flash SLC sarà migliore visto che le pagine sono molto più piccole (2-4kB vs. 16kB), i transistor contengono più carica e le performance in termini di tR e tPROG sono migliori.

Ieri mi sono letto l’articolo (tecnico).
Vero che apparentemente non parla di una generazione di V2 MLC 2bit in mezzo tra la prima 24L e la 32L TLC, ma non esclude che ci sia e non accenna all’uso 2bit prr queste celle.
Inoltre le analisi fatte all’epoca (scansione) parlano affermano che sono die da 86 Gbit, quindi esclude una capacità di die per TLC (anche li peró non è, diciamo “convinta” l’affermazione della capienza della die, ma quasi una deduzione).

Il dubbio viene, ok Black, ma non hai un documento più evidente?

Gundam1973
24-05-2025, 12:32
Non è che devi per forza installare il software del produttore, io non lo faccio…

appunto..tu...io si.

Hai consigli pertinenti?

Grazie!

Black (Wooden Law)
24-05-2025, 19:53
Ricapitolando, rimanendo in casa Crucial, mi bocci sia il p5+ che il T500 rimarrebbe solo il T705 andando quindi su gen5 o anche su gen4 ti risultano modelli decenti? Ho visto che son spuntati fuori anche i P310 che piu o meno sembrerebbero equivalenti i p5+ in quanto a prestazioni di targa.

Non ci sono altri modelli decenti di Crucial per PCIe 4.0, no. Il P310 è QLC e il P3 Plus idem (anche se il P310 è migliore) quindi non sono adatti per il SO.
Ieri mi sono letto l’articolo (tecnico).
Vero che apparentemente non parla di una generazione di V2 MLC 2bit in mezzo tra la prima 24L e la 32L TLC, ma non esclude che ci sia e non accenna all’uso 2bit prr queste celle.

Per la prima parte, Liupen, letteralmente non c’è alcun ISSCC delle 32L MLC, non esiste alcuna documentazione riguardo la loro esistenza (e tuttora Samsung rilascia documentazioni sulle NAND flash soltanto in presentazioni PDF o ISSCC, dove gli ISSCC sono un’estensione della prima). Il fatto, invece, che non ci sia scritto che queste NAND flash TLC operino in pMLC non c’entra, anche nell’ISSCC delle Intel 192L PLC non c’è scritto che operano in pQLC, eppure ne abbiamo la prova in più SSD, alcuni anche consumer. Alla fine sta al produttore dell’SSD decidere come far andare le NAND flash, se in TLC, pMLC, pSLC, ecc., non è una cosa riguardante le memorie in sé. Tu puoi impostare qualsiasi NAND flash per memorizzare meno bit di quanti ne memorizza solitamente (tranne le SLC ovviamente).
Inoltre le analisi fatte all’epoca (scansione) parlano affermano che sono die da 96 Gbit, quindi esclude una capacità di die per TLC

Questo è sbagliato teoricamente perché secondo questa (https://www.eetimes.com/samsungs-3d-v-nand-32l-vs-48l-just-vertical-expansion/#google_vignette) analisi di Jeongdong Choe (di cui mi fido parcheggio) le V2 hanno una capacità dei die di 85Gb, infatti le V2 TLC sono da 128Gb ma in pMLC 85Gb dal momento che le MLC sono il 33% meno dense.
Il die V-NAND Samsung da 32L (seconda generazione) contiene 10,67 GB (85,33 Gb).

Anche qui (https://www.3dincites.com/2014/08/samsungs-3d-vnand-flash-product-spires-el-dorado/) c’è scritto 86Gb:
Grazie agli esperti di Chipworks possiamo vedere come gli array di memoria sono nella seconda generazione V-NAND da 86 Gbit.
anche li peró non è, diciamo “convinta” l’affermazione della capienza della die, ma quasi una deduzione).

In che senso Liupen? C’è scritto dovunque nell’ISSCC che quelle NAND flash sono da 128Gb (in TLC), anche nell’abstract c’è scritto
Il dubbio viene, ok Black, ma non hai un documento più convincente?

Documento no, ma c’è il sito ufficiale di Samsung (https://news.samsung.com/global/samsung-electronics-starts-mass-production-of-industry-first-3-bit-3d-v-nand-flash-memory):
La V-NAND 3-bit è l’ultima generazione di dispositivi V-NAND di Samsung che usa 32 strati di celle impilati verticalmente per chip di memoria NAND. Ogni chip fornisce 128 gigabit (Gb) di storage di memoria.

EDIT: ho appena notato che hai scritto “86 Gb”. Perdonami Liupen, dopo 10 ore di lavoro son cotto, ricordavo avessi scritto “96Gb”.

Gundam1973
24-05-2025, 23:43
Non ci sono altri modelli decenti di Crucial per PCIe 4.0, no. Il P310 è QLC e il P3 Plus idem (anche se il P310 è migliore) quindi non sono adatti per il SO.


.

allora mi sa che aspetto ancora un po e vedo che offerte trovo in giro....puo essere che prendo una coppia di sk p41 da 2tb e trasferisco i due crucial sul muletto!
:D :D

giovanni69
25-05-2025, 09:04
Il P41 dopo l'aggiornamento del firmware mantiene le prestazioni in scrittura e non "scende" come prima.
Sono passati 2 mesi e le prestazioni rimangono costanti.

In rete però ho letto che qualcuno rileva ancora problemi,
nel mio caso è stato risolutivo.

Grazie per questa info @makka.
In che tipo di operazioni di scrittura hai notato di non avere più decadimenti di velocità come in precedenza?

Dove hai letto che qualcuno ha ancora problemi post aggiornamento fw?

@Liupen
25-05-2025, 10:07
Per la prima parte, Liupen, letteralmente non c’è alcun ISSCC delle 32L MLC, non esiste alcuna documentazione riguardo la loro esistenza (e tuttora Samsung rilascia documentazioni sulle NAND flash soltanto in presentazioni PDF o ISSCC, dove gli ISSCC sono un’estensione della prima). Il fatto, invece, che non ci sia scritto che queste NAND flash TLC operino in pMLC non c’entra, anche nell’ISSCC delle Intel 192L PLC non c’è scritto che operano in pQLC, eppure ne abbiamo la prova in più SSD, alcuni anche consumer. Alla fine sta al produttore dell’SSD decidere come far andare le NAND flash, se in TLC, pMLC, pSLC, ecc., non è una cosa riguardante le memorie in sé. Tu puoi impostare qualsiasi NAND flash per memorizzare meno bit di quanti ne memorizza solitamente (tranne le SLC ovviamente).


Questo è sbagliato teoricamente perché secondo questa (https://www.eetimes.com/samsungs-3d-v-nand-32l-vs-48l-just-vertical-expansion/#google_vignette) analisi di Jeongdong Choe (di cui mi fido parcheggio) le V2 hanno una capacità dei die di 85Gb, infatti le V2 TLC sono da 128Gb ma in pMLC 85Gb dal momento che le MLC sono il 33% meno dense.


Anche qui (https://www.3dincites.com/2014/08/samsungs-3d-vnand-flash-product-spires-el-dorado/) c’è scritto 86Gb:



In che senso Liupen? C’è scritto dovunque nell’ISSCC che quelle NAND flash sono da 128Gb (in TLC), anche nell’abstract. C’è scritto


Documento no, ma c’è il sito ufficiale di Samsung (https://news.samsung.com/global/samsung-electronics-starts-mass-production-of-industry-first-3-bit-3d-v-nand-flash-memory):


EDIT: ho appena notato che hai scritto “86 Gb”. Perdonami Liupen, dopo 10 ore di lavoro son cotto, ricordavo avessi scritto “96Gb”.

In effetti avevo fatto un errore di battitura e rileggendo qlc ora dopo ho corretto :D

Può essere che le cose non stanno esattamente come dici, almeno per la frase:
Molto semplicemente, Liupen, non sono mai esistite le Samsung 32L MLC. Le Samsung 32L (V2) sono nativamente TLC come riportato dovunque nell'ISSCC. Samsung è stata furba e ha detto che le NAND flash sono nativamente MLC perché non c'è differenza¹ tra pMLC e MLC e così facendo nessuno si è accorto (o perlomeno non se ne sono resi conto i recensori che ai tempi non c'era tutta la "libertà" di oggi con gli ISSCC).

Ieri in circa un ora di ricerca sul web (tempo contato purtroppo) ho trovato prova da Samsung dell'esistenza di una generazione V-Nand 32L MLC lanciata qlc mese prima delle TLC e la prova (nel senso citazione di Samsung stessa) che queste sono usate in modelli specifici.
Come ti ho già scritto è importante stabilire la dimensione del die, poichè dal part number già si ricava la struttura e trovare poi la dimensione è una semplice aritmetica.
Inoltre, in settimana, con un po di tempo, vorrei effettuare un analisi di confronto tra nand di seconda generazione. Se ci fosse (non lo so ora come ora) un SEM anche delle TLC contenute nel 850 EVO, si potrebbero rilevare differenze e somiglianze stabilendo se effettivamente è un unica produzione o sono due "tipi" come annunciato nel 2014 dal produttore.


PS. riguardo a https://news.samsung.com/global/samsung-electronics-starts-mass-production-of-industry-first-3-bit-3d-v-nand-flash-memory che si, è uno dei siti che ho aperto ieri, parla specificatamente delle V2 a 3bit, anzi è la "news" di presentazione che poi è stata illustrata all'ISSCC Conference.
Scrivono: Samsung ha introdotto la sua prima generazione di V-NAND (celle a 24 strati) nell'agosto 2013 e ha introdotto la seconda generazione di V-NAND (celle a 32 strati) con struttura a matrice di celle nel maggio 2014. Con il lancio della V-NAND a 32 strati e 3 bit, Samsung sta guidando l'era della memoria 3D accelerando l'evoluzione della tecnologia di produzione V-NAND.

Ovvio che per loro la gran novità è la TLC (128Gbit) che consente di arrivare a ssd da 2TB, ed è quella che costituisce oggetto di vanto e quindi di documenti tecnici (da settembre) e marketing nel corso del 2014, MA come scrivono, una precedente generazione presentata a maggio 214 è quella MLC (che TechInsights analizza e interpreta in die da 86 Gbit).

Vediamo. Sembra una sfida interessante se ci sono, e trovo, i documenti tecnici.

makka
25-05-2025, 11:13
Grazie per questa info @makka.
In che tipo di operazioni di scrittura hai notato di non avere più decadimenti di velocità come in precedenza?

Dove hai letto che qualcuno ha ancora problemi post aggiornamento fw?

Il decadimento di prestazioni non è che fosse visibile ad occhio,
ma si vedeva bene con un cristaldiskmark sul sequenziale.
Il primo test (seq1Mq8t1) in scrittura scendeva a 2400MB/s,
ora invece rimane a 6400MB/s.

Avevo letto qualcosa qu (https://www.reddit.com/r/buildapc/comments/1je0rud/hynix_p41_firmware_revealed_today/) su reddit,
nel primo post dicono di aver risolto con il nuovo firmware ma poi la velocità è scesa di nuovo, addirittura peggio di prima visto che arriva a 1500.
Quel thread poi è morto li, sarà un caso isolato.

Black (Wooden Law)
25-05-2025, 22:21
Ieri in circa un ora di ricerca sul web (tempo contato purtroppo) ho trovato prova da Samsung dell'esistenza di una generazione V-Nand 32L MLC lanciata qlc mese prima delle TLC e la prova (nel senso citazione di Samsung stessa) che queste sono usate in modelli specifici.

Dove Liupen, hai il link? Non ho trovato nulla da nessuna parte se non articoli imprecisi vista la non conoscenza che queste NAND flash sono di base delle TLC (anche perché è confermato da Samsung come linkato nel mio ultimo commento). Comunque potrebbe anch'essere che le V2 MLC esistano ma non penso siano mai state usate anche se non sono sicuro. Di sicuro c'è tanta confusione nel Web visto che anche Samsung le dà come TLC.

Comunque qui (https://news.samsung.com/global/samsung-electronics-takes-3d-memory-to-new-heights-with-sixth-generation-v-nand-ssds-for-client-computing) Samsung nella linea temporale di produzione delle NAND flash dice
"2nd-generation (32-layer) 128Gb 3-bit V-NAND"
Quindi TLC, non MLC. La "2nd-generation V-NAND SSD" presumo sia l'inizio della produzione a settembre 2014.
Come ti ho già scritto è importante stabilire la dimensione del die, poichè dal part number già si ricava la struttura e trovare poi la dimensione è una semplice aritmetica.

Ma ti riferisci sempre alle Samsung V2 vero? Se sì, come riportato nell'ISSCC, i die hanno una dimensione di 68,9 mm² e coincide anche con l'articolo di Jeongdong Choe per EE Times (non leggere "The 32L V-NAND die area is 84.3 mm²", lì Jeongdong intende tutta l'area del die mentre Samsung intende soltanto l'array di memoria con "scribe lane", infatti poco dopo Jeongdong dice "The NAND memory array area increased from 48.9 mm² to 68.7 mm²").
Inoltre, in settimana, con un po di tempo, vorrei effettuare un analisi di confronto tra nand di seconda generazione. Se ci fosse (non lo so ora come ora) un SEM anche delle TLC contenute nel 850 EVO, si potrebbero rilevare differenze e somiglianze stabilendo se effettivamente è un unica produzione o sono due "tipi" come annunciato nel 2014 dal produttore.

Devi però trovare sia una cross-section delle 32L TLC dell'850 EVO sia delle 32L MLC a patto che esistano e siano diverse dalle prime. :asd:
Il massimo che ho trovato sono le foto ritratte in questi tre siti:
- EE Times (https://www.eetimes.com/samsungs-3d-v-nand-32l-vs-48l-just-vertical-expansion/);
- 3D InCites (https://www.3dincites.com/2014/12/samsungs-3d-v-nand-flash-product-ceaselessly-marching/);
- PC Perspective (https://pcper.com/2016/03/v-nand-showdown-samsung-850-evo-v1-and-v2-compared-32-v2-vs-48-v3-layer-flash/).

Interessante è quest'immagine (https://pcper.com/wp-content/uploads/2015/08/f943-dsc04071-dxo.jpg) di un altro articolo di PC Perspective (https://pcper.com/2015/08/fms-2015-updated-samsung-adds-layers-to-its-3d-vnand-doubling-capacity-while-reducing-power-consumption/) sulla presentazione delle Samsung V3 dell'FMS 2015 che mette in paragone le V2 con le V3 specificando le prime come TLC, non MLC.
Ovvio che per loro la gran novità è la TLC (128Gbit) che consente di arrivare a ssd da 2TB, ed è quella che costituisce oggetto di vanto e quindi di documenti tecnici (da settembre) e marketing nel corso del 2014, MA come scrivono, una precedente generazione presentata a maggio 214 è quella MLC (che TechInsights analizza e interpreta in die da 86 Gbit).

Ma non l'hanno scritto Liupen, hanno semplicemente detto che la seconda generazione di memorie V-NAND è stata lanciata a maggio 2014 e che ha un numero di layer di 32. Al massimo c'è scritto roba come:
3-bit multi-level-cell (MLC)
Ma non significa che le NAND flash siano MLC, semplicemente vuol dire che sono TLC ma per marketing dicono MLC. Questo "trucchetto", purtroppo, lo fanno anche con gli attuali SSD come il 980 PRO (https://download.semiconductor.samsung.com/resources/data-sheet/Samsung-NVMe-SSD-980-PRO-Data-Sheet_Rev.2.1_230509_10129505081019.pdf) che è TLC e l'870 QVO (https://download.semiconductor.samsung.com/resources/data-sheet/Samsung_SSD_870_QVO_Data_Sheet_Rev1.1_10129514052310.pdf) che è QLC anche se sembra che abbiano smesso dal 990 PRO (https://download.semiconductor.samsung.com/resources/data-sheet/Samsung_NVMe_SSD_990_PRO_Datasheet_Rev.1.0.pdf) scrivendo esplicitamente "TLC":
Samsung V-NAND TLC
Avevo letto qualcosa qu (https://www.reddit.com/r/buildapc/comments/1je0rud/hynix_p41_firmware_revealed_today/) su reddit,
nel primo post dicono di aver risolto con il nuovo firmware ma poi la velocità è scesa di nuovo, addirittura peggio di prima visto che arriva a 1500.
Quel thread poi è morto li, sarà un caso isolato.

Certo che quei due utenti che segnalano performance basse potrebbero svuotarlo un po' l'SSD, uno ce l'ha al 91% e l'altro all'83%. Non penso che sia quello il problema delle performance basse ma magari c'è di mezzo anche un po' di usura (anche se son sicuro che siano dei casi isolati come dici tu, anche perché non ho riscontrato lamentele da tutti i miei conoscenti a cui ho fatto fare l'aggiornamento del firmware).

gabmac2
26-05-2025, 15:06
ho acquistato un pc in formato mini
c' è un Lexan NM100
è accettabile a livello di affidabilità?
in ogni caso è possibile inserirlo in un qualunque box usb nvme?

megthebest
26-05-2025, 15:49
ho acquistato un pc in formato mini
c' è un Lexan NM100
è accettabile a livello di affidabilità?
in ogni caso è possibile inserirlo in un qualunque box usb nvme?

l'NM100 è un M2 2280 ma ha interfaccia SATA, non NVME Pcie GenX
https://www.lexar.com/it/products/Lexar-NM100-M-2-2280-SATA-III-6Gb-s-SSD/
Come prestazioni è un pelo meglio dei classici SATA 2,5" e per averlo esterno devi assicurarti che il box sia compatibile con gli M2 SATA

gabmac2
26-05-2025, 16:42
l'NM100 è un M2 2280 ma ha interfaccia SATA, non NVME Pcie GenX
https://www.lexar.com/it/products/Lexar-NM100-M-2-2280-SATA-III-6Gb-s-SSD/
Come prestazioni è un pelo meglio dei classici SATA 2,5" e per averlo esterno devi assicurarti che il box sia compatibile con gli M2 SATA

perfetto
grazie
come modello è discretamente affidabile?
oppure è noto per qualche problema specifico?

megthebest
26-05-2025, 16:54
perfetto
grazie
come modello è discretamente affidabile?
oppure è noto per qualche problema specifico?

Non saprei, bisognerebbe aspettare Black o Liupen..potrebbero esserci svariate versioni con hardware diverso magari con lo stesso codice
Sarebbe utile una foto macro ai chip nand e al controller..

Black (Wooden Law)
26-05-2025, 17:14
come modello è discretamente affidabile?
oppure è noto per qualche problema specifico?

Non ci sono recensioni e foto senza etichetta che mostrano le NAND flash TLC che usa ma dalle foto pubblicizzate per la vendita dell'SSD si vede come controller o il Lexar DM918 (https://i.ebayimg.com/images/g/bG8AAOSw0EhlKF8z/s-l1600.webp) o il Marvell 88NV1120 (https://i.ebayimg.com/images/g/RNoAAOSw8hxlKF~4/s-l1600.webp) usato anche nell'NS100 linkato da Megthebest (che non è lo stesso SSD dell'NM100). In questa (https://nairobiultrabooks.odoo.com/web/image/product.product/5937/image_1024/LEXAR%20NM100%20INTERNAL%20SSD%20M.2%20SATA%20III%202280%20128GB?unique=0c51259) foto si potrebbe pensare che le NAND flash siano delle Lexar "CHGD8S5D" ma penso che sia un S/N inventato con Photoshop giusto per metterlo in vendita, anche perché se lo cerchi su Google non compare nessuna recensione/informazione utile.

Il Lexar DM918 è lo stesso controller dell'SSD esterno SL200 Portable (https://www.techpowerup.com/review/lexar-sl200-portable-ssd-1-tb/2.html). TPU dice che sembra essere un SM2258 ma non penso, anche perché altri siti lo prendono come un MAS0902A (https://www.inhdd.com/news-flash). Il MAS0902A è usato anche nell'NQ100 ed è un controller decisamente di fascia bassa, sulla carta leggermente migliore dell'S11 ma peggiore dell'88NV1120 (che è anch'esso fascia bassa ovviamente). In ogni caso, che sia un 88NV1120 o un MAS0902A, a patto che le NAND flash siano veramente TLC e non siano la feccia dell'umanità l'SSD un minimo affidabile dovrebbe esserlo ma non è detto. Sicuramente non ha mai dato problemi vista la grande penuria di informazioni riguardo ad esso e né il MAS0902A né l'88NV1120 sono conosciuti per essere dei controller inaffidabili.

Sul box NVMe ti ha già detto Megthebest: puoi metterlo in un box esterno mSATA ma non in uno NVMe, SATA lavora sul protocollo AHCI, non NVMe.

gabmac2
26-05-2025, 19:00
sicuramente ha prestazioni migliori di un A55, però
A55 però probabilmente è più affidabile
oppure no?
inserire due ssd in uno scatolino troppo piccolo.....
meglio evitare?
non avendo ancora letto le specifiche c' era convinzione sul fatto fosse nvme
se si guastasse il pc, erase ssd in box esterno e riconsegna
per quello chiedevo, ma è solo un aspetto secondario

Black (Wooden Law)
26-05-2025, 19:31
sicuramente ha prestazioni migliori di un A55, però
A55 però probabilmente è più affidabile
oppure no?

Non è più performante perché come dici tu l'NM100 non è un NVMe ma un mSATA e non è neanche detto che l'A55 sia più affidabile. In SSD del genere dove ci mettono qualsiasi porcheria di memorie non si possono fare confronti così generali, dipende tutto dal modello specifico di cui si parla. L'ultima versione che ho visto di A55 ha NAND flash B58R che sono TLC ma dai benchmark si comportavano come delle QLC, quindi possibilmente NAND flash di scarto. Mentre questo NM100 chi ci assicura che usi ancora NAND flash TLC e non QLC come tanti altri SSD cinesi (che poi fun fact: anche l'A55 in alcune versioni usa NAND flash QLC)? Quindi allo stesso momento non è detto che sia migliore come affidabilità.

inserire due ssd in uno scatolino troppo piccolo.....
meglio evitare?
non avendo ancora letto le specifiche c' era convinzione sul fatto fosse nvme
se si guastasse il pc, erase ssd in box esterno e riconsegna
per quello chiedevo, ma è solo un aspetto secondario

Vuoi mettere sia l'A55 che l'NM100 in un box esterno?

giovanni69
26-05-2025, 19:37
Il decadimento di prestazioni non è che fosse visibile ad occhio,
ma si vedeva bene con un cristaldiskmark sul sequenziale.
Il primo test (seq1Mq8t1) in scrittura scendeva a 2400MB/s,
ora invece rimane a 6400MB/s.

Avevo letto qualcosa qu (https://www.reddit.com/r/buildapc/comments/1je0rud/hynix_p41_firmware_revealed_today/) su reddit,
nel primo post dicono di aver risolto con il nuovo firmware ma poi la velocità è scesa di nuovo, addirittura peggio di prima visto che arriva a 1500.
Quel thread poi è morto li, sarà un caso isolato.

Ottimo miglioramento! :eek:

Esattamente con che tipo di scritture?

gabmac2
26-05-2025, 19:47
Non è più performante perché come dici tu l'NM100 non è un NVMe ma un mSATA e non è neanche detto che l'A55 sia più affidabile. In SSD del genere dove ci mettono qualsiasi porcheria di memorie non si possono fare confronti così generali, dipende tutto dal modello specifico di cui si parla. L'ultima versione che ho visto di A55 ha NAND flash B58R che sono TLC ma dai benchmark si comportavano come delle QLC, quindi possibilmente NAND flash di scarto. Mentre questo NM100 chi ci assicura che usi ancora NAND flash TLC e non QLC come tanti altri SSD cinesi (che poi fun fact: anche l'A55 in alcune versioni usa NAND flash QLC)? Quindi allo stesso momento non è detto che sia migliore come affidabilità.



Vuoi mettere sia l'A55 che l'NM100 in un box esterno?

inserire A55 internamento al pc
però mi sembra troppo
cosa dite?
grazie

Black (Wooden Law)
26-05-2025, 20:12
Ottimo miglioramento! :eek:

Esattamente con che tipo di scritture?

Scritture sequenziali ovviamente, quelle randomiche con blocchi da 4kB e QD1 non toccano neanche i 400 MB/s (https://mblogthumb-phinf.pstatic.net/MjAyMjA5MjlfODgg/MDAxNjY0Mzg0OTE0NjY0.PSzKC_J7oPNsTfZQzF4_V7WnOF2iPNIAx6qLncQiOjQg.EUcu5NhOS8BJWuioDet2n5NnRyVdUTLWvgvphhO_dqwg.JPEG.dntjqcjswp/%EB%B2%A4%EC%B9%98%EB%A7%88%ED%81%AC1.jpg?type=w800).
inserire A55 internamento al pc
però mi sembra troppo
cosa dite?
grazie

Non ho capito quello che vuoi fare sinceramente, A55 dentro al PC sostituendo l'NM100 che va in un box esterno? In caso, "però mi sembra troppo" credo sia un'esagerazione, bene o male sono lo stesso SSD NM100 e A55...

gabmac2
26-05-2025, 20:26
@ Black (Wooden Law)

no no
l' idea era di aggiungere un ssd A55 per storage (utilizzarli entrambi)
però se dici che la qualità tra NM100 e A55 è uguale non vale la pena, no?
inoltre due ssd in un pc in formato mini non è troppo?

Black (Wooden Law)
26-05-2025, 20:46
@ Black (Wooden Law)

no no
l' idea era di aggiungere un ssd A55 per storage (utilizzarli entrambi)
però se dici che la qualità tra NM100 e A55 è uguale non vale la pena, no?
inoltre due ssd in un pc in formato mini non è troppo?

Parlando di SSD SATA teoricamente non è troppo ma in questo caso è come se avessi (teoricamente) un SSD da dissipare visto che l'NM100 è M.2 2280 e non ha il case dissipante dell'A55 e di tutti gli altri SATA 2,5'', quindi forse è meglio non usare l'NM100 e l'A55 insieme. Comunque sì, secondo me non vale assolutamente la pena, IMHO sono bene o male uguali quegli SSD.

@Liupen
26-05-2025, 21:27
perfetto
grazie
come modello è discretamente affidabile?
oppure è noto per qualche problema specifico?

Lexar NM100 non è campione di affidabilità, se è quello che cerchi.
Ma d'altra parte sostituirlo con un altro ssd sata m.2 è problematico: di "buoni" non ce ne più. Passeresti da un dram less ad un altro.
Io guarderei se il mini pc adotta un ssd nvme.

Black (Wooden Law)
26-05-2025, 22:39
TrendForce (https://www.trendforce.com/presscenter/news/20250526-12591.html#:~:text=Home-,AI%20Demand%20Fuels%20Enterprise%20SSD%20Growth%3B%203Q25%20NAND%20Flash%20Prices,to%20Rise%20Further%2C%20Says%20TrendForce&text=TrendForce's%20latest%20investigations%20reveal%20that,the%20third%20quarter%20of%202025.) - dopo aver azzeccato l'aumento dei prezzi delle NAND flash del 3-8% nel 2Q25 - prevede un aumento della domanda degli SSD enterprise per gli investitori di IA e anche un aumento dei prezzi delle NAND flash del 5-10% nel 3Q25. A quanto pare i prezzi bassi degli SSD e delle NAND flash è durato soltanto per 3 mesi (1Q25), però c'è da dire che non abbiamo risentito parecchio del 3-8% del 2Q, speriamo che sia così anche per questo trimestre...

gabmac2
27-05-2025, 07:41
Lexar NM100 non è campione di affidabilità, se è quello che cerchi.
Ma d'altra parte sostituirlo con un altro ssd sata m.2 è problematico: di "buoni" non ce ne più. Passeresti da un dram less ad un altro.
Io guarderei se il mini pc adotta un ssd nvme.

non mi sembra purtroppo
un A55 però non migliora la situazione (per le cose più "importanti")?
NM100 hai avuto esperienze dirette con problematiche varie?
grazie

@Liupen
27-05-2025, 11:44
non mi sembra purtroppo
un A55 però non migliora la situazione (per le cose più "importanti")?
NM100 hai avuto esperienze dirette con problematiche varie?
grazie

Qualitativamente forse non cambierebbe nulla, certo mi darebbe più affidamento Silicon Power (quindi l'A55) rispetto a questo modello di Lexar.
Come puoi vedere anche tu, se scrivi Lexar NM100 su google e vai sulle immagini, ti escono almeno due ssd con diverso controller (lo noti perchè uno è in posizione ortogonale e l'altro diagonale). Questo non depone affatto per la qualità del dispositivo, probabile che Lexar abbia cambiato le componenti in corso. Un ssd almeno "affidabile" ha, dal punto di vista della produzione, una struttura e componenti caratteristiche, e "quella" sarebbe il punto di forza.

megthebest
27-05-2025, 12:08
non mi sembra purtroppo
un A55 però non migliora la situazione (per le cose più "importanti")?
NM100 hai avuto esperienze dirette con problematiche varie?
grazie

Però intanto fai una cosa, togli il Lexar dal miniPC, rimuovi l'adesivo e fai la foto macro alle nand e controller così da leggere eventuali sigle... almeno si riuscirebbe a dare qualche info in più e non solo "supposizioni" basate sul poco che circola sul web riguardo a questo Lexar NM100

giovanni69
27-05-2025, 16:40
Scritture sequenziali ovviamente, quelle randomiche con blocchi da 4kB e QD1 non toccano neanche i 400 MB/s (https://mblogthumb-phinf.pstatic.net/MjAyMjA5MjlfODgg/MDAxNjY0Mzg0OTE0NjY0.PSzKC_J7oPNsTfZQzF4_V7WnOF2iPNIAx6qLncQiOjQg.EUcu5NhOS8BJWuioDet2n5NnRyVdUTLWvgvphhO_dqwg.JPEG.dntjqcjswp/%EB%B2%A4%EC%B9%98%EB%A7%88%ED%81%AC1.jpg?type=w800).

Sì, come puoi forse intuire, cercavo di capire se quel sequenziale è tipo clonazione (è lì davvero le scritture sequenziali possono essere corpose e durare a lungo) o caricamento di sporadici grossi file...

Spero che @makka possa chiarire.

gabmac2
27-05-2025, 18:48
@megthebest

non vorrei piantino storie con la garanzia smontandolo
alla fine è un dispositivo per uso mediacenter, praticamente
tra un NM100 e un A55 non ci saranno probabilmente grosse differenze a livello di affidabilità
tenerlo d' occhio con Crystal e nel caso sostituirlo (ha comunque 3 anni di garanzia)?
inserire due ssd in una spazio così piccolo mi sembra troppo
voi lo fareste?
la preoccupazione c' è
grazie

Black (Wooden Law)
27-05-2025, 19:47
@megthebest

non vorrei piantino storie con la garanzia smontandolo
alla fine è un dispositivo per uso mediacenter, praticamente
tra un NM100 e un A55 non ci saranno probabilmente grosse differenze a livello di affidabilità
tenerlo d' occhio con Crystal e nel caso sostituirlo (ha comunque 3 anni di garanzia)?
inserire due ssd in una spazio così piccolo mi sembra troppo
voi lo fareste?
la preoccupazione c' è
grazie

L’A55 non penso sarebbe un grosso problema ma l’NM100 secondo me sì, o comunque potrebbe esserlo leggermente (non ho idea di quanto scaldino i controller SATA III scoperchiati però).

gabmac2
27-05-2025, 19:52
L’A55 non penso sarebbe un grosso problema ma l’NM100 secondo me sì, o comunque potrebbe esserlo leggermente (non ho idea di quanto scaldino i controller SATA III scoperchiati però).

quindi secondo Te un A55 non scalda, mentre NM100 si?
ovviamente sarebbero quasi sempre in idle (come accennavo è un mediacenter)
sia un A55 che un NM100 nello stesso piccolissimo case, per Te non sarebbe un problema?
grazie

megthebest
27-05-2025, 21:02
quindi secondo Te un A55 non scalda, mentre NM100 si?

ovviamente sarebbero quasi sempre in idle (come accennavo è un mediacenter)

sia un A55 che un NM100 nello stesso piccolissimo case, per Te non sarebbe un problema?

grazieMa puoi provare tu stesso, monitora le temperature con Crystaldiskinfo ora che hai solo NM100 sia in idle che facendo in test di velocità con crystaldiskmark.
Poi metti A55 e verifichi la differenza di temperatura di entrambi con gli stessi test.
Riguardo alla garanzia, l'adesivo su NM100 mica lo devi rimuovere tutto/buttare, lo riattacchi dopo aver visionato i chip, l'adesivo è riutilizzabile non inficia la garanzia (in genere è così)

Inviato dal mio Xiaomi 14 utilizzando Tapatalk

makka
28-05-2025, 09:12
Ti posso dire che anche il mio mini-pc ha "spazio" per un disco 2280 (nel mio caso nvme) e per un sata 2.5", io l'ho tenuto qualche mese con il suo ssd di serie affiancato da un crucial mx 500 per avere più spazio e non ho notato problemi di calore. Anche il mio è ad uso "mediacenter" con Serviio quindi non carichi pesanti.
Poi ho approfittato di un giorno di sconto e ho preso un ediloca da 1Tb e ora ho solo quello.
Gli nvme scaldano più dei sata (o msata) anche se il mio pc ha poche linee pci-ex quindi l'ssd come performance viene castrato alla fonte.
Secondo me puoi provare a mettere entrambi e vedere come va, installi un sw di monitoraggio temperature per essere sicuro e via.
Dipende anche da quanto è "mini" il tuo pc, il mio è circa 10x10x4 cm, quindi abbastanza piccolo.
Aggiungo che l'ssd "di serie" era un modello molto strano, avevo chiesto info anche qui e dai codici sembrava un "oem Dell" che in un pc della Beelink non si capisce cosa ci faccia !!
Ora è in un box usb ma ultimamente mi sta dando un sacco di problemi, se copio roba grossa il dissipatore del box si scalda moltissimo ma la velocità di trasferimento scende a valori infimi.....

gabmac2
28-05-2025, 09:29
grazie per i consigli e le esperienze dirette
il problema è uno solo
il pc verrà utilizzato solo per media center (al limite lettura posta e lettura pdf, quindi.....)
Lexar è una marca discreta in teoria, poi sul modello specifico.....(non scalda molto comunque)
la domanda brutale è:
secondo la Vostra esperienza, un A55 è molto più affidabile di un NM100 (nel medio-lungo periodo)?
la garanzia del pc è stata estesa a 6 anni (Lexar dovrebbe dare 3 anni)
nel caso, backup frequenti e si si pianta.....garanzia.....

@Liupen
28-05-2025, 09:46
Aggiungo che l'ssd "di serie" era un modello molto strano, avevo chiesto info anche qui e dai codici sembrava un "oem Dell" che in un pc della Beelink non si capisce cosa ci faccia !!
Ora è in un box usb ma ultimamente mi sta dando un sacco di problemi, se copio roba grossa il dissipatore del box si scalda moltissimo ma la velocità di trasferimento scende a valori infimi.....

Vuol dire che il controller scalda troppo ma anche che il dissipatore funziona.
Andrà in TT.

Purtroppo con la stagnazione della tecnologia (le nand sono quelle da anni), ci sono produttori la qualunque che si inventano fabbricatori di ssd e lo fanno anche per marchi blasonati. E poi.. difetti, rallentamenti, si disconnettono. Il web comincia ad essere sempre più pieno di questi "casi".


Black un argomento che hai trattato e che riprendo grazie a TechInsights.

- L'introduzione del bonding ibrido nei prodotti NAND 3D consente di risparmiare spazio sul die, spostando i circuiti di controllo periferici dal bordo del die a un die CMOS dedicato e bonded. Tuttavia, questo die logico CMOS dedicato richiede ulteriore silicio ed è destinato a diventare più complesso nel tempo, aumentando l'impatto ambientale complessivo.

- Con l'avvicinarsi dei 1000 piani di NAND 3D, l'impatto delle emissioni di Scope 1* diventa più pronunciato a causa della necessità di incidere accuratamente questi strati. L'efficienza di abbattimento sarà ulteriormente messa a fuoco.

*emissioni dirette di gas serra (GHG) del processo produttivo

A fronte di questo, nuove tecniche sono allo studio:

- Innovazioni promettenti, come l'incisione criogenica che utilizza composti chimici gassosi con un potenziale di riscaldamento globale (GWP) molto più basso, sono all'orizzonte per la futura produzione di NAND 3D. Tuttavia, la NAND 3D, come la logica avanzata, è destinata a passare a nuovi materiali di interconnessione on-die (come il molibdeno), e l'uso di una tecnologia a celle multilivello più densa solleva interrogativi sulla durata utile del dispositivo.

l'articolo chiude con:

Anche se l'abbattimento potesse essere spinto vicino al 100%, il contributo delle emissioni di Scopo 2 non sarebbe trascurabile. Essere più efficienti dal punto di vista energetico e utilizzare più fonti di energia rinnovabili diventeranno fondamentali per un futuro sostenibile in termini di costi ed emissioni, come nel caso dell'intera industria dei semiconduttori.


Mi sembra chiaro che dalla tecnologia di produzione delle nand ci si debba aspettare sempre più "inquinamento" e che l'eventuale "compensazione" ambientale si avrà solo se i paesi produttori attueranno a livello nazionale delle leggi apposite.. cosa che non faranno per il vile denaro.

Insomma: Nand is not green!

@Liupen
28-05-2025, 09:52
la domanda brutale è:
secondo la Vostra esperienza, un A55 è molto più affidabile di un NM100 (nel medio-lungo periodo)?
la garanzia del pc è stata estesa a 6 anni (Lexar dovrebbe dare 3 anni)
nel caso, backup frequenti e si si pianta.....garanzia.....

Non si può sapere, per due motivi:
1) nessuno ha esperienza diretta sui due modelli
2) il Lexar (ma anche l'A55 attuale) hanno componenti sconosciuti.

In questo caso la cosa logica da fare è lasciare il Lexar e realizzare un backup regolare dei dati.
Se in un futuro troverai a prezzo conveniente un MX500 o un 860 EVO (M.2) lo sostituirai.

gabmac2
28-05-2025, 10:22
Non si può sapere, per due motivi:
1) nessuno ha esperienza diretta sui due modelli
2) il Lexar (ma anche l'A55 attuale) hanno componenti sconosciuti.

In questo caso la cosa logica da fare è lasciare il Lexar e realizzare un backup regolare dei dati.
Se in un futuro troverai a prezzo conveniente un MX500 o un 860 EVO (M.2) lo sostituirai.

quindi secondo Te un A55, in teoria non può essere assolutamente (e sicuramente) migliore di un NM100 (certamente non in prestazioni)
ovviamente se dovesse saltare di netto NM100, i dati comunque non possono essere recuperati?
(non piace a nessuno che dati personali finiscano in mano ad altri se si dovesse riconsegnare il pc)
grazie

@Liupen
28-05-2025, 14:25
quindi secondo Te un A55, in teoria non può essere assolutamente (e sicuramente) migliore di un NM100 (certamente non in prestazioni)
ovviamente se dovesse saltare di netto NM100, i dati comunque non possono essere recuperati?
(non piace a nessuno che dati personali finiscano in mano ad altri se si dovesse riconsegnare il pc)
grazie

Non posso dirlo secondo me se: un A55, in teoria non può essere assolutamente (e sicuramente) migliore di un NM100, proprio per il motivo che ti ho detto sopra (che controller hanno? Che nand? Chi li stà producendo/assemblando?)
Posso dirti, e ti ho detto che mi fido di più della taiwanese Silicon Power che di Lexar.
Ma è una preferenza personale.

Il recupero dei dati da un ssd è difficile ma non impossibile a certe condizioni. Cripta i dati se non lo sono già dalla fabbrica.
Se usi Windows hai Bitlocker.
A meno che non ci sia motivo, dubito che un negozio o il produttore del pc, ci perda tempo: fuori l'ssd difettoso, dentro quello nuovo!

Black (Wooden Law)
28-05-2025, 17:21
Black un argomento che hai trattato e che riprendo grazie a TechInsights.

Ammazza oh, sono usciti due articoli (di cui solo uno accademico) e adesso l'LCA delle NAND flash e degli SSD è diventato un trend. :asd:
Se vai a vedere su Google Scholar ci sono pochi paper e la maggior parte sono più vecchi di 10 anni, quasi come se il problema fosse sorto ora.

Sai linkami l'articolo comunque? Ho cercato brevemente ma non ho trovato (hai per caso un account TechInsights?).
- L'introduzione del bonding ibrido nei prodotti NAND 3D consente di risparmiare spazio sul die, spostando i circuiti di controllo periferici dal bordo del die a un die CMOS dedicato e bonded. Tuttavia, questo die logico CMOS dedicato richiede ulteriore silicio ed è destinato a diventare più complesso nel tempo, aumentando l'impatto ambientale complessivo.

Chiaro, hybrid bonding significa "unire" due substrati di silicio tramite legami chimici, ovviamente ci sono due die e wafer diversi che raddoppiano - teoricamente - le emissioni. Sarebbe interessante anche sapere se l'azione in sé di creazione e uso dei legami di rame per i due substrati aumenti le emissioni. In questo (https://ieeexplore.ieee.org/abstract/document/9856846?casa_token=IqhaGvUVNI8AAAAA:wwCAvu7X1uMvKm_0swpTuhLDeW8_y5EhT8q9LuNhmWykFvfWWdJW3ql7V7tGIadA7z9vTr0h) paper che ho preso in considerazione per studiare un po' la tecnologia Xtacking non c'è scritto ma potrei documentarmi meglio sicuramente.
- Con l'avvicinarsi dei 1000 piani di NAND 3D, l'impatto delle emissioni di Scope 1* diventa più pronunciato a causa della necessità di incidere accuratamente questi strati. L'efficienza di abbattimento sarà ulteriormente messa a fuoco.

Anche questa mi sembra ovvia come cosa, come ho scritto in questo (https://www.hwupgrade.it/forum/showpost.php?p=48776760&postcount=23069) commento più layer equivalgono ad un maggior numero step di produzione quindi per una NAND flash da 1.000L il numero non sarebbe indifferente (circa 4.479... :eek:).
A fronte di questo, nuove tecniche sono allo studio:

- Innovazioni promettenti, come l'incisione criogenica che utilizza composti chimici gassosi con un potenziale di riscaldamento globale (GWP) molto più basso, sono all'orizzonte per la futura produzione di NAND 3D. Tuttavia, la NAND 3D, come la logica avanzata, è destinata a passare a nuovi materiali di interconnessione on-die (come il molibdeno), e l'uso di una tecnologia a celle multilivello più densa solleva interrogativi sulla durata utile del dispositivo.

Teoricamente con "incisione criogenica" si intende incisione con il plasma di fluoruro di idrogeno visto che qui (https://www.techpowerup.com/332081/plasma-technology-doubles-etch-rate-for-3d-nand-flash-memory) scrivono:
L'incisione cryo con il plasma di fluoruro di idrogeno ha mostrato un significativo aumento nella velocità di incisione in confronto agli scorsi processi di incisione cryo dove si usano separatamente le fonti di fluoro e idrogeno Ma la frase "in confronto agli scorsi processi di incisione di cryo" non mi torna, le attuali NAND flash usano l'incisone ionica reattiva, non incisione criogenica. Magari i ricercatori si riferiscono a qualche tipo di incisione criogenica in studio da un po' di tempo.

Devo studiare di più questa incisione e quello che propongono i ricercatori, in questi giorni se riesco mi metto sotto.
Anche se l'abbattimento potesse essere spinto vicino al 100%, il contributo delle emissioni di Scopo 2 non sarebbe trascurabile. Essere più efficienti dal punto di vista energetico e utilizzare più fonti di energia rinnovabili diventeranno fondamentali per un futuro sostenibile in termini di costi ed emissioni, come nel caso dell'intera industria dei semiconduttori.


Mi sembra chiaro che dalla tecnologia di produzione delle nand ci si debba aspettare sempre più "inquinamento" e che l'eventuale "compensazione" ambientale si avrà solo se i paesi produttori attueranno a livello nazionale delle leggi apposite.. cosa che non faranno per il vile denaro.

Sì, mi sembra di capire che TechInsights ci stia dicendo: "attualmente le emissioni delle NAND flash non sono un problema ma all'aumentare dei layer (specialmente avvicinandoci ai 1.000L) lo saranno se non vengono scoperti nuovi metodi per l'abbattimento delle emissioni. Visto che i nuovi metodi di incisione sono ancora in studio è meglio iniziare la produzione delle NAND flash tramite energia sostenibile".

Intano ho trovato questo (https://arxiv.org/abs/2207.10793) paper, mo' me lo leggo un po' e se ci trovo qualcosa di interessante lo scrivo.

Black (Wooden Law)
28-05-2025, 22:37
@Liupen giusto per aggiungere al tema "difficoltà future e attuali delle NAND flash 3D": ho appena finito di leggere questo interessantissimo paper del 2023 che parla dei trend, delle attuali e future sfide che questo tipo di memoria sta affrontando/dovrà affrontare e i punti più interessanti per le attuali sfide sono:
1. difficoltà nell'incisione ad alto allungamento (HAR) per la riduzione della velocità di incisione a seguito dell'aumento dell'allungamento dello stack NAND flash;
2. dal momento che all'aumentare dei layer sono necessari più X-decoder (selettori di pagine) e WL pad le dimensioni nella direzione X (quindi in lunghezza) stanno aumentando sempre di più. In parole povere la lunghezza delle scale (https://thememoryguy.com/wp-content/uploads/2017/08/2017-08-22-Samsungs-New-Stairstep-Etch-i.jpg) sta aumentando;
3. Deformazione del wafer NAND flash. A seguito dei processi di produzione delle NAND flash 3D il die viene deformato sempre di più specialmente per il fatto che c'è una deformazione della "sella" causata da un'asimmetria del chip nelle direzioni X e Y (quindi sia orizzontalmente e verticalmente).

Attuali soluzioni che si stanno mettendo in atto per i 3 problemi:
1. incisione criogenica. So di aver detto prima che il tipo di incisione che viene effettuato per le NAND flash 3D è a ioni reattivi (che è un tipo di incisione a secco) ma a quanto pare Samsung la sta già usando dalle NAND flash V8 sfruttando una maggiore la velocità di incisione di 1,5 volte e ottenendo anche il più piccolo pitch ("distanza" diciamo) di sempre tra i fori dei canali. Se usata in futuro questo tipo di incisione può anche mitigare la necessità di dover impilare continuamente layer data la sua capacità di incisione (e questo, secondo lo studio, abbassa i costi di produzione);
2. struttura multifori, ossia l'incisione di più fori negli spazi WL. Siccome c'è una certa distanza in nm tra una WL e l'altra la struttura multifori prevede di incidere più fori per ogni "porzione" di WL migliorando lo scaling laterale. Per migliorare la scalatura orizzontale è stato anche tenuto in conto la riduzione del pitch dei fori e del pitch delle BL (punto sul quale la ricerca è ferma dall'inizio della produzione delle NAND flash 3D, nel senso che il pitch delle BL non viene ridotto al di sotto dei 40 nm da sempre) ma ciò non è possibile visto che aumenterebbe l'interferenza cella a cella e la perdita di carica;
3. "tecnologie di gestione dello stress" come "film stress change", deposizione posteriore (BSSCC teoricamente) e la ricottura (le ultime due sono già in uso da YMTC).

Per il resto, sulle sfide del futuro il paper non mostra altre problematiche, piuttosto offre soltanto soluzioni sotto studio. Una novità per migliorare lo scaling verticale (quindi per l'implicazione dei layer) è "trap-cut" che consiste nel tagliare alcuni layer di intrappolamento delle cariche (quindi alcuni layer di Si₃N₄) per curare maggiormente le perdita di carica. Quindi quando guardi il canale in verticale vedi che ci sono delle celle "staccate" tra di loro (ricordando, a mio parere, le celle floating gate) anziché il solito strato di Si₃N₄ bello condiviso con le cariche.

Ultima cosa è l'uso di uno stack ferroelettrico anziché CTF. In poche parole anziché usare uno strato di Si₃N₄ per l'intrappolamento degli elettroni viene usato un materiale ferroelettrico che è in grado di mantenere della carica grazie al campo elettrico prodotto dalla polarizzazione ferroelettrica. Utilizzando una polarizzazione ferroelettrica si riesce ad avere delle tensioni operative e applicative (cioè quelle di programmazione e cancellazione) inferiori visto che non c'è iniezione di carica come nelle celle CTF convenzionali che usano l'effetto tunnel Fowler-Nordheim.

Mi scuso per il commento più tecnico del solito, comunque. Spero di esser stato chiaro e di facile comprensione.

unnilennium
29-05-2025, 08:24
Leggo con interesse, anche se capisco poco, però non capisco cosa sia "...abbadando anche i costi di produzione..."

Inviato dal mio 23127PN0CG utilizzando Tapatalk

Black (Wooden Law)
29-05-2025, 08:58
Leggo con interesse, anche se capisco poco, però non capisco cosa sia "...abbadando anche i costi di produzione..."

Inviato dal mio 23127PN0CG utilizzando Tapatalk

Volevo dire "abbassando" ma dopo una certa ora sono abbastanza cotto e scrivo male. Scusami per l'errore e grazie della correzione Unnilennium.

frafelix
29-05-2025, 10:31
Qualche aggiornamento sul secure erase: confermo che con parted magic si crea una chiavetta usb avviabile e tra i vari software c'è anche il secure erase per ssd.

Invece per quanto riguarda trim e gc segnalo che su mac (Mac studio con Sequoia 15.5, quindi l'ultimo so) ho provato con software di recupero dati a recuperare dei documenti e ci sono riuscito. Tra l'altro controllando quello che potevo recuperare, ci sono cose anche vecchie di anni!
Ma il trim non dovrebbe entrare in funzione appena si cancella un file?
Idem il gc, non dovrebbe entrare in funzione negli stati di idle di sistema/ssd?

Dai vostri ultimi commenti avevo letto che entravano in gioco in fase di riscrittura delle celle, ma io sapevo che per esempio che il trim agiva "subito" e non solo in fase di riscrittura se la cella è piena

Black (Wooden Law)
29-05-2025, 12:21
Invece per quanto riguarda trim e gc segnalo che su mac (Mac studio con Sequoia 15.5, quindi l'ultimo so) ho provato con software di recupero dati a recuperare dei documenti e ci sono riuscito. Tra l'altro controllando quello che potevo recuperare, ci sono cose anche vecchie di anni!
Ma il trim non dovrebbe entrare in funzione appena si cancella un file?
Idem il gc, non dovrebbe entrare in funzione negli stati di idle di sistema/ssd?

Dai vostri ultimi commenti avevo letto che entravano in gioco in fase di riscrittura delle celle, ma io sapevo che per esempio che il trim agiva "subito" e non solo in fase di riscrittura se la cella è piena

Magari molto semplicemente il TRIM ha informato il garbage collection su altri blocchi che non contenevano questi dati vecchi di anni che dici tu. Se mi dici che questi dati sono qualche centinaia di MB o al massimo qualche unità di GB potrei pensare a questo caso ma se mi dici che la quantità di dati è ingente allora potrei pensare che il TRIM e/o il GC non funzioni bene con l'SSD/il SO. Comunque sì, il TRIM ogni qualvolta che riceve una richiesta di cancellazione informa immediatamente il GC che ci sono dei blocchi da cancellare. Tieni però conto che il GC prende alcuni dati "buoni" del blocco, li copia e li incolla in altri blocchi, quindi non cancella completamente tutto il blocco teoricamente.

Leggendo molto velocemente questo (https://ieeexplore.ieee.org/document/8887298) paper mi sembra di capire che il funzionamento del TRIM e del GC dipenda dal file system, dal SO e dell'SSD (anche se purtroppo hanno testato soltanto vecchi SSD SATA):
Nonostante le diverse differenze tra i Solid State Drives selezionati, 18 iterazioni hanno mostrato che il Garbage Collection e il TRIM hanno agito rispettivamente il 67% e il 61%. [...] Sia il Garbage Collection che il TRIM hanno preso di mira i dati cancellati senza eccezioni. Tuttavia, il Garbage Collection non si verifica dopo l'eliminazione dei dati e può essere distinta da TRIM.

Questa la conclusione. C'è però da dire che questo paper ha testato soltanto Windows 10, Ubuntu 18.04 e Debian 9.4 con rispettivamente NTFS, EXT4 e XFS, non macOS con APFS.

Quest'altro (https://borecraft.com/PDF/Books%2C%20Chapters%2C%20Theses/Impact_of_TRIM_on_Forensics.pdf) studio, invece, mi sembra più completo visto che usa anche macOS (Catalina). Qui i ricercatori hanno indagato sul recupero dei dati a seguito del TRIM e del GC con diversi SSD SATA (due NS100, un BX500, un A400 e un 870 EVO). Con macOS Catalina è stato scoperto che indipendentemente dall'uso dell'SSD (25%, 50% e 75%) la probabilità del recupero dei dati dopo 24 ore è di circa del 52-54%. Il problema è che sono 24 ore, non anni (anche se il primo paper è arrivato fino a 84 ore). :asd:

In conclusione ti direi che non siamo in conoscenza dell'efficienza del TRIM sul lungo termine ma che a rigor di logica, non essendo un algoritmo perfetto, alcune pagine da cancellare possano anche non esser toccate per molto tempo. Ti direi anche che dipende molto dalla quantità di file di cui si parla, dal tipo di file, dalle loro dimensioni, dall'SSD specifico, ecc.

frafelix
29-05-2025, 13:11
La dimensione totale dei file recuperabili era di qualche gb. I Mac sono sempre stati noiosi dal punto di vista degli ssd, le prime versioni dei so che supportavano gli ssd erano compatibili solo con quelli montati di fabbrica, se lo sostituivi o lo aggiungevi ad un Mac che ne era sprovvisto avevi il trim non funzionante e dovevi installare programmi di terze parti per abilitarlo (all'epoca c'era Trim Enabler). Mi pareva di aver letto che non so da quale versione di so in poi avevano aperto a tutti gli ssd il pieno supporto.

Il gc è gestito solo a livello firmware dell'ssd. Il trim invece è un comando che parte da so e poi gestito dal firmware. La domanda per il trim è: teoricamente viene lanciato appena di cancella un file oppure viene lanciato nel momento in cui si tenta di scrivere su una cella (semplificando) che è piena di dati vecchi (cioè cancellabili)?

sbaffo
29-05-2025, 13:12
ho un'ipotesi un po strana ma magari... in caso di "incidente" cioè crash/bsod/salta corrente l'SSD si ferma così com'è senza portare a termine il trim/gc. Al riavvio si ricorda di farlo o dimentica tutto e la roba vecchia resta lì per anni finchè non viene sovrascritta per caso?
Idem se all'inizio è stato usato con un un S.O. senza trim, ma è improbabile.
Edit: leggo ora il commento di frafelix che su Mac in effetti era così...

frafelix
29-05-2025, 13:15
Teoricamente il gc dovrebbe intervenire comunque anche dopo spegnimento improvviso visto che è indipendente dal so. Nel caso dello spegnimento improvviso magari il comando trim non passa, ma poi a livello so quel file non c'è più e ci dovrebbe pensare il gc anche senza il trim

Black (Wooden Law)
29-05-2025, 13:45
Il gc è gestito solo a livello firmware dell'ssd. Il trim invece è un comando che parte da so e poi gestito dal firmware. La domanda per il trim è: teoricamente viene lanciato appena di cancella un file oppure viene lanciato nel momento in cui si tenta di scrivere su una cella (semplificando) che è piena di dati vecchi (cioè cancellabili)?

Appena si cancella un file, quindi appena mandi il comando di cancellatura al controller dell'SSD.
Nel caso dello spegnimento improvviso magari il comando trim non passa, ma poi a livello so quel file non c'è più e ci dovrebbe pensare il gc anche senza il trim

Eh ma come fa il GC a operare senza il TRIM? Nel senso, se la cronologia degli eventi è: TRIM -> spegnimento dell'SSD e del SO -> riaccensione dell'SSD senza che il comando TRIM gli sia arrivato, come fa il GC a sapere che deve cancellare le pagine di X blocco se questa informazione non gli è mai arrivata? O lo fa a priori o lo farà più avanti quando l'SSD arriverà a una capienza di dati occupati maggiore, o sbaglio?

frafelix
29-05-2025, 14:03
Appena si cancella un file, quindi appena mandi il comando di cancellatura al controller dell'SSD.

Quindi mi risulta difficile capire perché posso recuperare file di anni fa...

Eh ma come fa il GC a operare senza il TRIM? Nel senso, se la cronologia degli eventi è: TRIM -> spegnimento dell'SSD e del SO -> riaccensione dell'SSD senza che il comando TRIM gli sia arrivato, come fa il GC a sapere che deve cancellare le pagine di X blocco se questa informazione non gli è mai arrivata? O lo fa a priori o lo farà più avanti quando l'SSD arriverà a una capienza di dati occupati maggiore, o sbaglio?

Mi verrebbe da pensare, a logica, che il gc si rifaccia anche alla mappatura dei dati del so, se per il so quel dato non esiste più anche se non ti ho mandato il comando trim tu cancellalo, magari facendo un controllo sull'intero spazio disponibile ogni tot tempo. Ma è una mia supposizione.
Altrimenti i crash o spegnimenti improvvisi non li gestisci, anche con gli hd meccanici quello che faceva fede erano i "puntatori" ai file, poi lì non c'era tutta la parte di blocchi e pagine delle nand

Black (Wooden Law)
29-05-2025, 14:19
Quindi mi risulta difficile capire perché posso recuperare file di anni fa...

Anche a me risulta difficile pensare ad una cosa del genere ma te l'ho scritto prima quello che penso: magari ha dato "priorità" ad altre pagine e altri blocchi. Ma 'sto Mac è usato parecchio, molto poco... ?
Mi verrebbe da pensare, a logica, che il gc si rifaccia anche alla mappatura dei dati del so, se per il so quel dato non esiste più anche se non ti ho mandato il comando trim tu cancellalo, magari facendo un controllo sull'intero spazio disponibile ogni tot tempo. Ma è una mia supposizione.
Altrimenti i crash o spegnimenti improvvisi non li gestisci, anche con gli hd meccanici quello che faceva fede erano i "puntatori" ai file, poi lì non c'era tutta la parte di blocchi e pagine delle nand

Mh, quindi tu dici che il GC potrebbe avere una sorta di mappatura di pagina da cancellare, già cancellate e tutto. Ci sta come cosa ma non saprei sinceramente, bisognerebbe testare se i dati cancellati prima subito prima della mancanza di corrente siano recuperabili o meno.

frafelix
29-05-2025, 14:32
Anche a me risulta difficile pensare ad una cosa del genere ma te l'ho scritto prima quello che penso: magari ha dato "priorità" ad altre pagine e altri blocchi. Ma 'sto Mac è usato parecchio, molto poco... ?

Diciamo uso medio, è il mio pc dell'ufficio e ci faccio lavori di grafica, quindi creo e cancello file di piicole-medie dimensioni (500kb-20mb) + browsing + email

Mh, quindi tu dici che il GC potrebbe avere una sorta di mappatura di pagina da cancellare, già cancellate e tutto. Ci sta come cosa ma non saprei sinceramente, bisognerebbe testare se i dati cancellati prima subito prima della mancanza di corrente siano recuperabili o meno.

Più che l'ssd in sé, pensavo che l'andasse a leggere dal so per fare un controllo se quello che ha lui memorizzato come dati di blocchi, pagine e nand corrisponde con quello del so come puntatori logici. Ma ripeto sono tutte supposizioni, comunque è sempre il so che comanda e credo che i file nel so ragionino come prima con gli hd meccanici a puntatori sugli indirizzi di memoria (che ora invece di essere settori di un piatto sono blocchi e pagine su nand)

Nicodemo Timoteo Taddeo
29-05-2025, 14:56
Domanda perché questo non l'ho capito:

Questi file sono dichiarati recuperabili e/o sono stati effettivamente recuperati da un programma di recupero dati, cioè dopo l'operazione sono effettivamente disponibili, si "aprono" e sono funzionanti come dovrebbero?


Grazie.

frafelix
29-05-2025, 15:02
Sì, provato su una decina di immagini da circa 3mb e comunque sulla maggior parte faceva vedere l'anteprima del file, quindi direi che tutti quelli erano recuperabili al 100%

Nicodemo Timoteo Taddeo
29-05-2025, 15:15
Sì, provato su una decina di immagini da circa 3mb e comunque sulla maggior parte faceva vedere l'anteprima del file, quindi direi che tutti quelli erano recuperabili al 100%

Ed allora mi sembra ovvio che il firmware di quel SSD per qualche ragione non ha fatto il Trim ed il GC. Non funziona così di norma, i file non possono essere recuperati ancor meno a distanza di anni.

frafelix
29-05-2025, 15:19
Ni, nel senso che dei file che ho recuperato, nello stesso giorno (poco più di 1 mese fa) ne avevo fatto altri 30 che in parte c'erano ed in parte no, quindi qualcosa effettivamente ha cancellato, oppure ci ho riscritto sopra io nel frattempo, questo non lo possiamo sapere

sbaffo
29-05-2025, 15:32
La dimensione totale dei file recuperabili era di qualche gb. I Mac sono sempre stati noiosi dal punto di vista degli ssd, le prime versioni dei so che supportavano gli ssd erano compatibili solo con quelli montati di fabbrica, se lo sostituivi o lo aggiungevi ad un Mac che ne era sprovvisto avevi il trim non funzionante e dovevi installare programmi di terze parti per abilitarlo (all'epoca c'era Trim Enabler). Mi pareva di aver letto che non so da quale versione di so in poi avevano aperto a tutti gli ssd il pieno supporto.

Il gc è gestito solo a livello firmware dell'ssd. Il trim invece è un comando che parte da so e poi gestito dal firmware. La domanda per il trim è: teoricamente viene lanciato appena di cancella un file oppure viene lanciato nel momento in cui si tenta di scrivere su una cella (semplificando) che è piena di dati vecchi (cioè cancellabili)? Non è che sono dati così vecchi che risalgono proprio a quando Mac gestiva male il trim? Una volta "dimenticati" dal s.o. per qualunque motivo sono rimasti lì inerti come sugli hd meccanici.

Ma anche dagli studi riportati l'efficienza dei sistemi di pulizia non sembra altissima, si parla di percentuali di recupero fino al 50%, in pratica lanci una monetina e scommeti a testa o croce...
(ok dice 24ore, ma se ha avuto tempi di idle sufficienti dovrebbero essere già cancellati, altrimenti non li cancellerà mai..., se non ha avuto un attimo di idle in 24ore era un server, ma non credo sia il caso).

frafelix
29-05-2025, 15:38
Il Mac studio ha due anni, quindi ha un so sicuramente senza il blocco degli ssd di terze parti e comunque è nato con ssd di fabbrica ed in questo caso il problema non si pone. Il mac durante la giornata di tempi di inattività da parte mia ne ha visto che spesso sono in giro per l'azienda, lui in background ha solo le email e time machine su nas, quindi in un mese avrebbe avuto il tempo per il gc.

Secondo me le possibilità sono due:
1 - ci sono dei problemi a livello di so Mac o di firmware ssd
2 - il trim ed il gc non sono così veloci come abbiamo sempre saputo/studiato

@Liupen
29-05-2025, 15:45
Ammazza oh, sono usciti due articoli (di cui solo uno accademico) e adesso l'LCA delle NAND flash e degli SSD è diventato un trend. :asd:
Se vai a vedere su Google Scholar ci sono pochi paper e la maggior parte sono più vecchi di 10 anni, quasi come se il problema fosse sorto ora.

Sai linkami l'articolo comunque? Ho cercato brevemente ma non ho trovato (hai per caso un account TechInsights?).


Intano ho trovato questo (https://arxiv.org/abs/2207.10793) paper, mo' me lo leggo un po' e se ci trovo qualcosa di interessante lo scrivo.

Ciao, non ho ancora aperto il pdf che mi hai passato... mancato il tempo e mi sto dividendo nel preparare una cosa.

Per TechInsights mi sono iscritto alla newsletter, basta l'account gmail https://auth.svc.techinsights.com/login/username?app=UNIFIEDUI-PROFILE
Questo l'articolo
https://library.techinsights.com/hg-asset/f3c0e905-cc88-4d3b-9146-e883f11eab43#moduleName=Analysis+View&reportCode=SME-2505-801&subscriptionId=null&channelId=null&reportName=Toward+1000-Layer+3D+NAND%253A+Cutting+Emissions+with+Cryo+Etching+%2526+Green+Power



@Liupen giusto per aggiungere al tema "difficoltà future e attuali delle NAND flash 3D": ho appena finito di leggere questo interessantissimo paper del 2023 che parla dei trend, delle attuali e future sfide che questo tipo di memoria sta affrontando/dovrà affrontare e i punti più interessanti per le attuali sfide sono:
1. difficoltà nell'incisione ad alto allungamento (HAR) per la riduzione della velocità di incisione a seguito dell'aumento dell'allungamento dello stack NAND flash;
2. dal momento che all'aumentare dei layer sono necessari più X-decoder (selettori di pagine) e WL pad le dimensioni nella direzione X (quindi in lunghezza) stanno aumentando sempre di più. In parole povere la lunghezza delle scale (https://thememoryguy.com/wp-content/uploads/2017/08/2017-08-22-Samsungs-New-Stairstep-Etch-i.jpg) sta aumentando;
3. Deformazione del wafer NAND flash. A seguito dei processi di produzione delle NAND flash 3D il die viene deformato sempre di più specialmente per il fatto che c'è una deformazione della "sella" causata da un'asimmetria del chip nelle direzioni X e Y (quindi sia orizzontalmente e verticalmente).

Attuali soluzioni che si stanno mettendo in atto per i 3 problemi:
1. incisione criogenica. So di aver detto prima che il tipo di incisione che viene effettuato per le NAND flash 3D è a ioni reattivi (che è un tipo di incisione a secco) ma a quanto pare Samsung la sta già usando dalle NAND flash V8 sfruttando una maggiore la velocità di incisione di 1,5 volte e ottenendo anche il più piccolo pitch ("distanza" diciamo) di sempre tra i fori dei canali. Se usata in futuro questo tipo di incisione può anche mitigare la necessità di dover impilare continuamente layer data la sua capacità di incisione (e questo, secondo lo studio, abbassa i costi di produzione);
2. struttura multifori, ossia l'incisione di più fori negli spazi WL. Siccome c'è una certa distanza in nm tra una WL e l'altra la struttura multifori prevede di incidere più fori per ogni "porzione" di WL migliorando lo scaling laterale. Per migliorare la scalatura orizzontale è stato anche tenuto in conto la riduzione del pitch dei fori e del pitch delle BL (punto sul quale la ricerca è ferma dall'inizio della produzione delle NAND flash 3D, nel senso che il pitch delle BL non viene ridotto al di sotto dei 40 nm da sempre) ma ciò non è possibile visto che aumenterebbe l'interferenza cella a cella e la perdita di carica;
3. "tecnologie di gestione dello stress" come "film stress change", deposizione posteriore (BSSCC teoricamente) e la ricottura (le ultime due sono già in uso da YMTC).

Per il resto, sulle sfide del futuro il paper non mostra altre problematiche, piuttosto offre soltanto soluzioni sotto studio. Una novità per migliorare lo scaling verticale (quindi per l'implicazione dei layer) è "trap-cut" che consiste nel tagliare alcuni layer di intrappolamento delle cariche (quindi alcuni layer di Si₃N₄) per curare maggiormente le perdita di carica. Quindi quando guardi il canale in verticale vedi che ci sono delle celle "staccate" tra di loro (ricordando, a mio parere, le celle floating gate) anziché il solito strato di Si₃N₄ bello condiviso con le cariche.

Ultima cosa è l'uso di uno stack ferroelettrico anziché CTF. In poche parole anziché usare uno strato di Si₃N₄ per l'intrappolamento degli elettroni viene usato un materiale ferroelettrico che è in grado di mantenere della carica grazie al campo elettrico prodotto dalla polarizzazione ferroelettrica. Utilizzando una polarizzazione ferroelettrica si riesce ad avere delle tensioni operative e applicative (cioè quelle di programmazione e cancellazione) inferiori visto che non c'è iniezione di carica come nelle celle CTF convenzionali che usano l'effetto tunnel Fowler-Nordheim.

Mi scuso per il commento più tecnico del solito, comunque. Spero di esser stato chiaro e di facile comprensione.

Si molto tecnico ;) forse troppo per assimilarlo così velocemente mentre ti rispondo.

lo stack ferroelettrico è da un po di anni che è al centro degli studi, a vari livelli. Se non si sviluppa o paura che sia epr la difficoltà di lavorazione o per i costi.
Ma di questo, a brani, ho letto qualcosa.

L'incisione criogenica non la conosco. Proprio zero.
Per l'incisione multifori, capisco grossomodo la questione del miniaturizzare senza poi avere interferenza da vicinanza di due o più WL, ma non vado più in la di cosa leggo.
Stress dei materiali? Nada. Argomento di cui non so nulla.



Qualche aggiornamento sul secure erase: confermo che con parted magic si crea una chiavetta usb avviabile e tra i vari software c'è anche il secure erase per ssd.

Invece per quanto riguarda trim e gc segnalo che su mac (Mac studio con Sequoia 15.5, quindi l'ultimo so) ho provato con software di recupero dati a recuperare dei documenti e ci sono riuscito. Tra l'altro controllando quello che potevo recuperare, ci sono cose anche vecchie di anni!
Ma il trim non dovrebbe entrare in funzione appena si cancella un file?
Idem il gc, non dovrebbe entrare in funzione negli stati di idle di sistema/ssd?

Dai vostri ultimi commenti avevo letto che entravano in gioco in fase di riscrittura delle celle, ma io sapevo che per esempio che il trim agiva "subito" e non solo in fase di riscrittura se la cella è piena

Domanda forse banale non conoscendo macOS... il Trim è attivo?
Seconda cosa, hai fatto il recupero dati ok, ma l'ssd l'hai formattato?
Se hai fatto sull'ssd un vero Secure Erase, ti assicuro che non hai più dati perchè le celle sono state cancellate, quindi se dopo un SE hai i dati ...il software ha mentito ;)

Il trim entra in funzione non quando si cancella un file ma quando il tipo di dato cancellato è sopra una certa dimensione oppure periodicamente secondo la schedulazione del sistema operativo.
Quindi se il controller rileva un cambiamento "sostanzioso" può richiedere un TRIM al OS.
Il TRIM dal canto suo NON è un comando prioritario, quindi viene messo in coda e se non fatto allo spegnimento del pc, riprende con l'accensione (in idle è il momento).
Essendo un messaggio non è la cancellazione automatica di dati ma appunto solo l'invalidazione degli indici a livello di mappatura.
Il GC parte dopo, autonomamente e controllato dal controller, se necessario, e prima di scrivere nuovi dati.

Quindi diciamo che se tutto funziona come deve un dato cancellato e trimmato non è più visibile proprio perche sparisce dalla mappatura e il software di recupero, che legge la mappatura, trova altro e non quello.
Alcuni ssd pur segnando il dato trimmato come non più valido, lo lasciano nella mappatura, ed in questo caso se non c'è anche lo zampino anche del GC, l'ssd (TRIM attivo) risulta leggibile. Purtroppo GC si attiva statisticamente di più con ssd, molto usati, dati di piccole dimensioni, pieni. Insomma non sempre prima di una nuova scrittura il controller ha la necessità di spostare parti di pagine per liberare blocchi da scrivere, molte volte i blocchi sono ancora vergini o co sono già pronti.

Il passo in più è quando con un ssd criptato si cerca di recuperare i dati ed allora la mappatura perde la codifica risultando totalmente irrecuperabile (ovviamente vale per tutti gli storage).

Questi più o meno i casi che possono capitare.



In conclusione ti direi che non siamo in conoscenza dell'efficienza del TRIM sul lungo termine ma che a rigor di logica, non essendo un algoritmo perfetto, alcune pagine da cancellare possano anche non esser toccate per molto tempo. Ti direi anche che dipende molto dalla quantità di file di cui si parla, dal tipo di file, dalle loro dimensioni, dall'SSD specifico, ecc.

Molto vero. A volte però si tende a confondere il TRIM come comunicazione, dal GC come algoritmo di spostamento dei "rifiuti"... la mente e il braccio; ma cosa non fà recuperare più il dato è la sparizione dell'indice dalla mappatura: occhio non vede, dato non trova!


Il gc è gestito solo a livello firmware dell'ssd. Il trim invece è un comando che parte da so e poi gestito dal firmware. La domanda per il trim è: teoricamente viene lanciato appena di cancella un file oppure viene lanciato nel momento in cui si tenta di scrivere su una cella (semplificando) che è piena di dati vecchi (cioè cancellabili)?

Spero con cosa ho scritto sopra sia chiaro:

TRIM è il raffronto di mappatura logica di OS versus fisica su ssd; un messaggio.
Non prioritario e differibile.
Penso che ogni ssd stabilisca le quantità di dati cancellati che lo fanno richiedere.

GC è un algoritmo del controller (ssd) come il wear leveling, serve a spostare dai blocchi in cancellazione prima di una nuova scrittura, i frammenti di pagina valida su altre pagine "libere" ma su blocchi occupati in prevalenza da dati "buoni".
Si attiva solo prima di una nuova scrittura. Non sempre, dipende dalla necessità.



Appena si cancella un file, quindi appena mandi il comando di cancellatura al controller dell'SSD.


Eh ma come fa il GC a operare senza il TRIM? Nel senso, se la cronologia degli eventi è: TRIM -> spegnimento dell'SSD e del SO -> riaccensione dell'SSD senza che il comando TRIM gli sia arrivato, come fa il GC a sapere che deve cancellare le pagine di X blocco se questa informazione non gli è mai arrivata? O lo fa a priori o lo farà più avanti quando l'SSD arriverà a una capienza di dati occupati maggiore, o sbaglio?

Negativo.

Il processo (semplificato) è:

cancellazione file corposo --> TRIM --> modifica valori mappatura

DOPO

necessità di scrivere un nuovo dato --> CG in funzione del TRIM (dato valido su blocco da cancellare) = sposto frammento pagina valida + cancello blocco + riscrivo pagina su altro blocco in consapevolezza di WA) + scrivo su blocco cosa vuole utente.




Quindi mi risulta difficile capire perché posso recuperare file di anni fa...



Mi verrebbe da pensare, a logica, che il gc si rifaccia anche alla mappatura dei dati del so, se per il so quel dato non esiste più anche se non ti ho mandato il comando trim tu cancellalo, magari facendo un controllo sull'intero spazio disponibile ogni tot tempo. Ma è una mia supposizione.
Altrimenti i crash o spegnimenti improvvisi non li gestisci, anche con gli hd meccanici quello che faceva fede erano i "puntatori" ai file, poi lì non c'era tutta la parte di blocchi e pagine delle nand

Eccolo che ci sei.

Black (Wooden Law)
29-05-2025, 16:18
Per TechInsights mi sono iscritto alla newsletter, basta l'account gmail https://auth.svc.techinsights.com/login/username?app=UNIFIEDUI-PROFILE
Questo l'articolo
https://library.techinsights.com/hg-asset/f3c0e905-cc88-4d3b-9146-e883f11eab43#moduleName=Analysis+View&reportCode=SME-2505-801&subscriptionId=null&channelId=null&reportName=Toward+1000-Layer+3D+NAND%253A+Cutting+Emissions+with+Cryo+Etching+%2526+Green+Power

Grazie della fonte Liupen e ti ringrazio anche per avermi informato su questa cosa di TechInsighs, non pensavo che si potesse leggermente spulciare la loro (nuova) piattaforma senza pagare.
Il trim entra in funzione non quando si cancella un file ma quando il tipo di dato cancellato è sopra una certa dimensione oppure periodicamente secondo la schedulazione del sistema operativo.
Quindi se il controller rileva un cambiamento "sostanzioso" può richiedere un TRIM al OS.

Ma come mai 'sta roba? Non l'avevo mai sentita, più che altro ho sempre sentito che il TRIM agisce sui file cancellati a priori senza specificare se siano di grandi o piccole dimensioni.

@Liupen
29-05-2025, 16:31
Tu pensa adesso che sei sul pc in questo momento, probabilmente il tuo sistema operativo per farti vedere e agire su questa pagina di browser staà anche facendo micro scritture (metti che siano le classiche 4K con QD2 - 4... molte di queste al temine della sessione (pensa ai pochi MB del file di paging o dell'avvio rapido di Windows) verranno cancellati.
Se per ogni inezia dovesse lanciare un TRIM non sarebbe efficiente.

sbaffo
29-05-2025, 16:59
ma cosa non fà recuperare più il dato è la sparizione dell'indice dalla mappatura: occhio non vede, dato non trova! Però sugli hd meccanici non era così, i dati si potevano recuperare leggendoli a basso livello anche a file system corrotto, fat andata, purchè non fossero ancora stati sovrascritti. Poi solo i migliori software riuscivano a ricostruire i file e non tutti, molti restavano a spezzoni, però diciamo che con un po di fortuna molti si recuperavano.

Non so se per gli ssd valga lo stesso, suppongo sia più diffcile per via della maggior "frammentazione" tra le celle, ma potrebbe essere possibile... o no?

Black (Wooden Law)
29-05-2025, 17:01
Tu pensa adesso che sei sul pc in questo momento, probabilmente il tuo sistema operativo per farti vedere e agire su questa pagina di browser staà anche facendo micro scritture (metti che siano le classiche 4K con QD2 - 4... molte di queste al temine della sessione (pensa ai pochi MB del file di paging o dell'avvio rapido di Windows) verranno cancellati.
Se per ogni inezia dovesse lanciare un TRIM non sarebbe efficiente.

E magari, aggiungo, se per ogni inezia del genere venisse fatto eseguire il GC a seguito delle segnalazioni TRIM si aumenterebbe il WAF inutilmente. Direi che ha senso come cosa, grazie Liupen.

Ultima cosa: hai idea in che ordine di grandezza sia la quantità di dati segnalati dal TRIM? Quindi se il TRIM agisce su file nell'ordine di centinaia di MB, decine di MB, unità di GB, ecc.
Non so se per gli ssd valga lo stesso, suppongo sia più diffcile per via della maggior "frammentazione" tra le celle, ma potrebbe essere possibile... o no?

Se i dati non fanno parte di un gruppo sostanzioso di dati mi viene da pensare che possano essere cancellati più avanti visto che il TRIM funzionerebbe più in là quando gli arriverebbe altri dati da cancellare. Però come ha detto Liupen il TRIM non è un comando prioritario, magari per alcuni dati ci vuole parecchio perché vengano cancellati dal controller dell'SSD visto che ci sono altri comandi più importanti.

Non ho risposto a questo, comunque:
Ma anche dagli studi riportati l'efficienza dei sistemi di pulizia non sembra altissima, si parla di percentuali di recupero fino al 50%, in pratica lanci una monetina e scommeti a testa o croce...
(ok dice 24ore, ma se ha avuto tempi di idle sufficienti dovrebbero essere già cancellati, altrimenti non li cancellerà mai..., se non ha avuto un attimo di idle in 24ore era un server, ma non credo sia il caso).

Anche a me fa rimanere il fatto che nell'SSD non vengano cancellati i dati immediatamente e che il TRIM abbia un'efficienza di massimo il 67% fino a 84 ore, però se l'SSD viene martellato parecchio di comandi da eseguire ed essendo il TRIM un comando non prioritario penso che sia normale il fatto che il drive sia più impegnato a gestire altre cose anziché i vecchi dati da cancellare nei blocchi NAND flash, e penso anche che per questo motivo l'efficienza non sia del 100%. Poi mettici anche qualche errore da parte del TRIM e dal GC, il fatto che se si parla di tanti dati da dover cancellare l'SSD possa richiedere più tempo idle... forse è normale. Non so, mie ipotesi.

@Liupen
29-05-2025, 19:59
Però sugli hd meccanici non era così, i dati si potevano recuperare leggendoli a basso livello anche a file system corrotto, fat andata, purchè non fossero ancora stati sovrascritti. Poi solo i migliori software riuscivano a ricostruire i file e non tutti, molti restavano a spezzoni, però diciamo che con un po di fortuna molti si recuperavano.

Non so se per gli ssd valga lo stesso, suppongo sia più diffcile per via della maggior "frammentazione" tra le celle, ma potrebbe essere possibile... o no?

Gli hdd memorizzano la mappatura su una specifica area del piatto (anche se poi come l'ssd modifica la mappatura sul buffer della DRAM) e lo fanno come tutto, sequenzialmente. E' diverso da un gruppo di blocchi su nand e non esistono ne TRIM ne Garbage Collection che agiscono.
Il recupero è da difficile a impossibile.
Senza TRIM la mappatura non cancella gli indici, così anche per una rottura improvvisa. L'ssd viene preso, scollegato dal controller, innestato in un software che imita il controller e letto a livello di cella I/0.
In caso di perdita di mbr o formattazione accidentale diventa da difficile ea impossibile (con strumenti normali da DR non forensi).

L'ssd che mettiamo viene formattato per sbaglio, o se perde l'mbr, si trova un controller che mediante TRIM, riscrive una mappatura (filesystem, LBA-logical block addressing) azzerandone i valori. Questa mappatura è copiata su nand quindi del vecchio filesystem, non rimane nessun riferimento. In seguito a questo poi il GC e WL comincia a cancellare blocchi e scrivere nuovi.

L'hdd a cui succede la stessa cosa, ha una mappatura (anzi diverse versioni) ancora memorizzate sequenzialmente sui piattelli, per cui non solo è possibile uppare i dati dell'ultima, ma addirittura ci si può trovare frammenti di file di vecchie installazioni. Il software di recupero a questo punto, come dici, trova i dati veri, perchè i piattelli li conservano, se non sono sovrascritti.
In teoria se non è intervenuto un danno fisico, o una riscrittura accidentale, il recupero è totale +spezzoni vari illeggibili.

E magari, aggiungo, se per ogni inezia del genere venisse fatto eseguire il GC a seguito delle segnalazioni TRIM si aumenterebbe il WAF inutilmente. Direi che ha senso come cosa, grazie Liupen.

Ultima cosa: hai idea in che ordine di grandezza sia la quantità di dati segnalati dal TRIM? Quindi se il TRIM agisce su file nell'ordine di centinaia di MB, decine di MB, unità di GB, ecc.


Se i dati non fanno parte di un gruppo sostanzioso di dati mi viene da pensare che possano essere cancellati più avanti visto che il TRIM funzionerebbe più in là quando gli arriverebbe altri dati da cancellare. Però come ha detto Liupen il TRIM non è un comando prioritario, magari per alcuni dati ci vuole parecchio perché vengano cancellati dal controller dell'SSD visto che ci sono altri comandi più importanti.

Non lo so, penso faccia parte del firmware un poo come scoprire come è fatto l'algoritmo di GC o di WL; puoi solo immaginare come funzioni in teoria.

Sul TRIM però ti dico, non sarebbe impossibile scoprirlo. Visto che è Windows che messaggia e che ci sono software che monitorizzano la qualsiasi cosa, tipo registro di sistema; ci sarà il modo di vedere il TRIM quando si attiva, la frequenza per lo meno; magari facendo delle prove (cancellando file via via crescenti ad esempio, o aprendo e chiudendo sessioni di lavoro, o ...qualsiasi altra idea venga in mente).

nesema
29-05-2025, 20:07
Ciao a tutti

https://i.imgur.com/nUSbKOR.jpeg

http://www.ssk.cn/Product_Center_details/21.html

usato poco

:rolleyes:

devo preoccuparmi ?

frafelix
29-05-2025, 20:28
Domanda forse banale non conoscendo macOS... il Trim è attivo?
Seconda cosa, hai fatto il recupero dati ok, ma l'ssd l'hai formattato?
Se hai fatto sull'ssd un vero Secure Erase, ti assicuro che non hai più dati perchè le celle sono state cancellate, quindi se dopo un SE hai i dati ...il software ha mentito ;)

Sì, il trim è attivo e non ho formattato niente. Il mac l'ho preso circa due anni fa nuovo e da lì utilizzato normalmente. Ieri per puro caso ho voluto provare un paio di programmi recupero dati perchè avevo perso dei dati da cartelle di cui non faccio il backup con time machine e da qui la scoperta! Dai software di recupero ci sono dati anche di due anni fa...

Il trim entra in funzione non quando si cancella un file ma quando il tipo di dato cancellato è sopra una certa dimensione oppure periodicamente secondo la schedulazione del sistema operativo.
Quindi se il controller rileva un cambiamento "sostanzioso" può richiedere un TRIM al OS.

Io avevo capito/credevo che invece il trim veniva lanciato appena cancellato un file, è dai tempi di win7 che sapevo questa cosa e anche in prima pagina il post di Tennic dove faceva la prova del trim si vedeva che dopo qualche decina di secondi dal comando di delete si metteva in funzione.
Se funziona come dici tu dopo un tot di scritture chi lo decide il so o il firmware dell'ssd? Varia da ssd a ssd? C'è una regola?
Il trim schedulato lo lascerei fuori dall'equazione in quanto anche se il comando è lo stesso ha una logica di avvio diversa (su richiesta o periodica a prescindere).

Il TRIM dal canto suo NON è un comando prioritario, quindi viene messo in coda e se non fatto allo spegnimento del pc, riprende con l'accensione (in idle è il momento).
Essendo un messaggio non è la cancellazione automatica di dati ma appunto solo l'invalidazione degli indici a livello di mappatura.
Il GC parte dopo, autonomamente e controllato dal controller, se necessario, e prima di scrivere nuovi dati.
Quindi diciamo che se tutto funziona come deve un dato cancellato e trimmato non è più visibile proprio perche sparisce dalla mappatura e il software di recupero, che legge la mappatura, trova altro e non quello.
Alcuni ssd pur segnando il dato trimmato come non più valido, lo lasciano nella mappatura, ed in questo caso se non c'è anche lo zampino anche del GC, l'ssd (TRIM attivo) risulta leggibile. Purtroppo GC si attiva statisticamente di più con ssd, molto usati, dati di piccole dimensioni, pieni. Insomma non sempre prima di una nuova scrittura il controller ha la necessità di spostare parti di pagine per liberare blocchi da scrivere, molte volte i blocchi sono ancora vergini o co sono già pronti.

Ok che non è un comando prioritario, ma dopo due anni lo avrà trovato il tempo per partire e finire! Con "l'invalidazione degli indici a livello di mappatura" intendi i puntatori logici dei file del so? Quindi il trim cancella i puntatori ma lascia i dati sulle celle? Anche qui mi pareva che il trim cancellasse effettivamente i dati ed il gc servisse per sopperire a eventuali mancanze del trim per qualsiasi motivo e per coprire le esigenze del wl che nello spostaggio dei dati avesse quindi bisogno anche di un trim automatico non dipendente dal so.
L'ssd del mac è da 500gb e pieno per circa 100gb, quindi decisamente con molto spazio libero.

Spero con cosa ho scritto sopra sia chiaro:
TRIM è il raffronto di mappatura logica di OS versus fisica su ssd; un messaggio.
Non prioritario e differibile.
Penso che ogni ssd stabilisca le quantità di dati cancellati che lo fanno richiedere.
GC è un algoritmo del controller (ssd) come il wear leveling, serve a spostare dai blocchi in cancellazione prima di una nuova scrittura, i frammenti di pagina valida su altre pagine "libere" ma su blocchi occupati in prevalenza da dati "buoni".
Si attiva solo prima di una nuova scrittura. Non sempre, dipende dalla necessità.

Vedi le domande sopra, a cui aggiungerei: ma il gc entra in gioco solo prima della riscrittura di una cella? Se l'ssd fosse sempre in idle perchè non fa quello che deve fare in modo che la riscrittura sia più veloce visto che a quel punto non bisogna prima cancellare le celle? Forse aumenta la wa?

unnilennium
29-05-2025, 20:29
Ciao a tutti

https://i.imgur.com/nUSbKOR.jpeg

http://www.ssk.cn/Product_Center_details/21.html

usato poco

:rolleyes:

devo preoccuparmi ?

secondo me si. non so che disco ci sia dentro al box, ma visto il prezzo sospetto non sia niente di buono, consiglio di salvare il salvabile e chiedere assistenza al venditore, sperando possa garantire la sostituzione o il rimborso.

Nicodemo Timoteo Taddeo
29-05-2025, 20:29
Direi di sì, l'SSD è chiaramente seminuovo ed ha lavorato pochissimo, appena 4 TB di scritture che per un 2TB di capienza sono niente.
Viene segnalato un valore di Riserva disponibile che ammonta a 44 (2C in esadecimale), giusto per raffronto l'SSD che sto adoperando in questo notebook, capienza 500 GB, dopo cinque anni e con una decina di TB di scritture il livello è ancora di 100 come era da nuovo.

Ora può essere che si tratti di qualche falsa indicazione ma sarebbe opportuno chiedere al produttore, se ancora in garanzia, e vedere se è il caso di provvedere ad una sostituzione o restituzione avvalendosi della garanzia.

Black (Wooden Law)
29-05-2025, 20:34
Ciao a tutti

https://i.imgur.com/nUSbKOR.jpeg

http://www.ssk.cn/Product_Center_details/21.html

usato poco

:rolleyes:

devo preoccuparmi ?

Teoricamente sì, ti devi preoccupare perché quell'attributo indica la quantità di blocchi riservati per sostituire quelli difettosi e se si abbassa vuol dire che ci sono dei blocchi riservati che sono stati usati (e se ci sono dei blocchi difettosi vuol dire che alcune celle NAND flash son difettose). Se dentro questa USB ci sono dati importanti fai backup e cambia USB, altrimenti cambia USB e basta.

EDIT: vedo ora che non è una chiavetta USB il drive ma un SSD esterno. L'SSD è di una marca sconosciuta e se ti dà questi problemi con soltanto 4TB di scritture mi viene da pensare che il grado delle NAND flash sia davvero basso.

Nicodemo Timoteo Taddeo
29-05-2025, 21:45
EDIT: vedo ora che non è una chiavetta USB il drive ma un SSD esterno.

Le semplici chiavette USB non forniscono dati SMART che io sappia, c'è qualche novità in questo? :)

Black (Wooden Law)
29-05-2025, 22:18
Le semplici chiavette USB non forniscono dati SMART che io sappia, c'è qualche novità in questo? :)

No, no, assolutamente, mi son solo confuso io.

nesema
30-05-2025, 07:44
Direi di sì, l'SSD è chiaramente seminuovo ed ha lavorato pochissimo, appena 4 TB di scritture che per un 2TB di capienza sono niente.
Viene segnalato un valore di Riserva disponibile che ammonta a 44 (2C in esadecimale), giusto per raffronto l'SSD che sto adoperando in questo notebook, capienza 500 GB, dopo cinque anni e con una decina di TB di scritture il livello è ancora di 100 come era da nuovo.

Ora può essere che si tratti di qualche falsa indicazione ma sarebbe opportuno chiedere al produttore, se ancora in garanzia, e vedere se è il caso di provvedere ad una sostituzione o restituzione avvalendosi della garanzia.

grazie a tutti per le risposte

è un SSD di backup lavorativo (doppio a sua volta) .... finchè va lo tengo, nel caso mi lascia i dati sono ANCHE su altri dischi :)

nel frattempo vedo possibili sostituzioni di migliore qualità :D

@Liupen
30-05-2025, 12:40
Sì, il trim è attivo e non ho formattato niente. Il mac l'ho preso circa due anni fa nuovo e da lì utilizzato normalmente. Ieri per puro caso ho voluto provare un paio di programmi recupero dati perchè avevo perso dei dati da cartelle di cui non faccio il backup con time machine e da qui la scoperta! Dai software di recupero ci sono dati anche di due anni fa...


Ok che non è un comando prioritario, ma dopo due anni lo avrà trovato il tempo per partire e finire! Con "l'invalidazione degli indici a livello di mappatura" intendi i puntatori logici dei file del so? Quindi il trim cancella i puntatori ma lascia i dati sulle celle? Anche qui mi pareva che il trim cancellasse effettivamente i dati ed il gc servisse per sopperire a eventuali mancanze del trim per qualsiasi motivo e per coprire le esigenze del wl che nello spostaggio dei dati avesse quindi bisogno anche di un trim automatico non dipendente dal so.
L'ssd del mac è da 500gb e pieno per circa 100gb, quindi decisamente con molto spazio libero.

Io avevo capito/credevo che invece il trim veniva lanciato appena cancellato un file, è dai tempi di win7 che sapevo questa cosa e anche in prima pagina il post di Tennic dove faceva la prova del trim si vedeva che dopo qualche decina di secondi dal comando di delete si metteva in funzione.
Se funziona come dici tu dopo un tot di scritture chi lo decide il so o il firmware dell'ssd? Varia da ssd a ssd? C'è una regola?
Il trim schedulato lo lascerei fuori dall'equazione in quanto anche se il comando è lo stesso ha una logica di avvio diversa (su richiesta o periodica a prescindere).

Vedi le domande sopra, a cui aggiungerei: ma il gc entra in gioco solo prima della riscrittura di una cella? Se l'ssd fosse sempre in idle perchè non fa quello che deve fare in modo che la riscrittura sia più veloce visto che a quel punto non bisogna prima cancellare le celle? Forse aumenta la wa?




Dati di due anni fà che hai cancellato? sicuro che erano cancellati?
Sarebbe strano, a meno che il mac non usa un ssd vecchio o senza supporto TRIM o senza supporto Read After Trim.
Fai il recupero col software, ma dubito siano veramente integri se hai il TRIM attivo.

Meglio chiarire il quando agisce il TRIM.
Le microscritture non determinano il lancio del TRIM, file utente si.
La frequenza di aggiornamento data dal TRIM dal punto di vista di un sistema operativo, che mette il comando in coda non prioritaria, può essere lento tanto che ad esempio se formatto accidentalmente un ssd, posso staccarlo dalla corrente e correre da un DR che mettendolo in Factory mode / ROM Mode può recuperare i dati.
Dal nostro (umano) punto di vista è probabile che almeno una chiamata di TRIM venga fatta per ogni sessione di lavoro/accensione, se non più frequente se l'utente cancella dati.

Per invalidazione degli indici a livello di mappatura intendo i puntatori alla P2P pointer (Physical‐to‐Physical pointer), il numero di pagina fisica (PPN), che indica dove è effettivamente memorizzato quel blocco di dati su flash. Se questo viene annullato, perdendo la corrispondenza di dove si trovano i frammenti di file sulle nand flash, è come se perdi il file (anche se il GC ancora non ha eliminato il file).

Quindi il trim cancella i puntatori ma lascia i dati sulle celle? SI. Non che lo faccia il TRIM direttamente, lo fà il controller quando riceve il TRIM.
Il GC è la conseguenza diretta del cancellare i dati prima eliminati.
Ma GC è un algoritmo che esiste anche negli ssd senza TRIM o con TRIM disattivato.
Senza TRIM il Controller tende a spostare le pagine "buone" con meno efficienza (lentamente e con più frammentazione, quindi scrivendo di più), ma lo fà comunque

Scrivi: Anche qui mi pareva che il trim cancellasse effettivamente i dati ed il gc servisse per sopperire a eventuali mancanze del trim per qualsiasi motivo e per coprire le esigenze del wl che nello spostaggio dei dati avesse quindi bisogno anche di un trim automatico non dipendente dal so.

Come leggi sopra, devi considerare tre elementi separati e ognuno ha il suo compito. TRIM se vogliamo è stato l'ultimo elemento ad essere stato aggiunto agli SSD ...nel 200x? (ignoro)

E' importante sapere la gerarchia: più celle accorpate sono la PAGINA (la pagina è l'unità più piccola dove memorizzare); più pagine accorpate costituiscono il BLOCCO logico. Regola: l'ssd scrive a pagine ma può/deve cancellare tutto il blocco.


Algoritmo GC: cerca i blocchi da cancellare per far stare nuovi dati e come effetto sposta le pagine (frammenti di file) validi su altre pagine in blocchi validi non pieni.
Algoritmo WL: distribuisce le scrittura in prevalenza su pagine costituite da celle che hanno meno scritture.
Messaggio TRIM: il controller riceve dall'OS tutti gli indirizzi logici dei dati non validi e modifica la P2P

Tutti gli algoritmi + la mappatura P2P = FTL


Scrivi: ma il gc entra in gioco solo prima della riscrittura di una cella? SI. e..NO. Non è detto che all'accensione dell'ssdd non ci siano comandi di GC in coda. Quindi la risposta è: quello (prima della riscrittura di una cella) è il momento per cui serve questo algoritmo, ma è anche possibile che in idle ci sia GC.

Scrivi: Se l'ssd fosse sempre in idle perchè non fa quello che deve fare in modo che la riscrittura sia più veloce visto che a quel punto non bisogna prima cancellare le celle? Forse aumenta la wa?
Eh, bella domanda! Me lo sono chiesto anch'io.
Il fatto che siamo abituati a pensare ad un processo alla volta, ma in realtà di cose ne succedono tante insieme, compresa SI, la cancellazione di blocchi anche in stato di idle. GC è permanente.
Pensa ad esempio alla cache di scrittura. Li il controller DEVE sempre liberare spazio e se non è una cache statica, vuol dire che sono blocchi sparsi ovunque.
Quindi quando entra un dato nuovo in un ssd ci sono già celle libere lavoro dei un GC attivato precedentemente.
Però il meccanismo del GC è il medesimo: localizzare pagine, spostarle, cancellare l'ex blocco scritto.



Continuando a parlare di recupero dati su ssd, una certa quantità di dati utente potrebbe essere memorizzata nello spazio riservato OP, cache d scrittura, ecc. Realisticamente, questo non rappresenta un problema per gli utenti di computer privati: è improbabile che si esegua un ripristino dati chip-off per cercare di accedere a piccole quantità di dati. Serve un recupero DR con strumenti hardware non riuscirebbe ne R-Studio ne Easeus.

Per approfondire l'argomento ti lascio dei link che appunto trattano di cosa succede quando un file fine cancellato da un ssd.
Sono cose un po settoriali, forensi ma prima ti lascio due concetti base: DRAT e DRAZ.

Originariamente non appena un blocco di memoria viene segnalato come “liberato” tramite il comando TRIM, ogni successiva operazione di lettura sul medesimo blocco restituiva l’ultima versione pre-TRIM del dato, fintanto che non veniva scritto un nuovo dato sul blocco.
Questo modo di trattare i dati cancellati - ssd di una certa età - è stato considerato pericoloso perchè lasciava gli ssd a rischio recupero fraudolento.
E' anche il metodo delle USB schede di memoria in genere.

DRAT (Deterministic Read After Trim) è un metodo di Erase del dato per cui non appena un blocco di memoria viene segnalato come “liberato” tramite il comando TRIM, ogni successiva operazione di lettura sul medesimo blocco restituirà sempre lo stesso contenuto (“deterministico”), indipendentemente dal fatto che il dato fisico sia già stato cancellato internamente o meno. Questo contenuto deterministico può essere: zero, uno o un valore caratteristico per il firmware dell'ssd.

Con DZAT (Deterministic Zeros After Trim), dopo il comando TRIM, ogni lettura del blocco restituisce sempre e soltanto zeri fino a quando quel blocco non venga nuovamente scritto con nuovi dati. In questo modo, una volta trimmato, il blocco appare immediatamente “pieno di zeri” al sistema operativo o agli strumenti di forensics, rendendo impossibile recuperare il contenuto precedente via comandi standard.

https://belkasoft.com/ssd-2016-part3
https://blog.elcomsoft.com/2019/01/life-after-trim-using-factory-access-mode-for-imaging-ssd-drives/
https://pcprompt.in/services/ssd-data-recovery/


Edit.

frafelix
30-05-2025, 13:09
Sì, dati di due anni fa e tranquillamente recuperabili (ci ho provato ieri) e dubito che i nuovi mac abbiano ssd senza supporto TRIM o senza supporto Read After Trim...

Quindi il trim non cancella MAI fisicamente il dato, cancella solo i puntatori (credo che qui da anni tutti, me compreso, avessero capito il contrario), quindi per complicarci la vita abbiamo dato un nome ad una cosa che veniva già fatta con gli hd meccanici senza che l'utente ne fosse a conoscenza e senza che avesse un nome (era implicito nella cancellazione del file).
La maggior parte delle incomprensioni deriva solo da cosa fa esattamente il trim

Il gc quindi è l'unico imputato alla effettiva cancellazione dei dati.

Grazie per i link, ora me li leggo, ma quindi per tornare all'esempio che ti avevo fatto prima del trim in prima pagina di Tennic, in quel caso che restituiva solo 0, significa che l'ssd in questione supportava il DZAT, immagino.

Tutta la mia incomprensione derivava dalla convinzione (appresa in anni di forum) che il trim cancellasse fisicamente i dati quando lanciato. Una volta appurato che non è così il fatto che sia possibile recuperare i dati non mi pare così strano visto che il tutto dipende dal gb e quindi dalla sua implementazione nel firmware che varierà a seconda del produttore e con possibilità di vari bug.
Quindi a questo punto anche l'affermazione che su ssd è più difficile recuperare i dati è vera a metà, nel senso che rispetto ai meccanici dove per non recuperare i file dovevi averci scritto sopra (anche parzialmente), quì in più hai il possibile (nel senso che non sai quando accadrà) intervento del gc.

s12a
30-05-2025, 13:21
Anni fa c'era un programma per Windows, chiamato TrimCheck, che controllava il corretto funzionamento del trim analizzando il contenuto di certi settori dopo la cancellazione. Con gli SSD che ho avuto al tempo, il trim faceva immediatamente riportare zeri da parte dei settori cancellati.

frafelix
30-05-2025, 13:48
Sì esatto, e da lì l'errata convinzione che il trim cancellasse fisicamente il dato, oltre al fatto delle prime discussioni tecniche dove da sempre si diceva che il trim cancellava fisicamente.
Anche tu la sapevi così?

@Liupen
30-05-2025, 14:27
Sì, dati di due anni fa e tranquillamente recuperabili (ci ho provato ieri) e dubito che i nuovi mac abbiano ssd senza supporto TRIM o senza supporto Read After Trim...

Quindi il trim non cancella MAI fisicamente il dato, cancella solo i puntatori (credo che qui da anni tutti, me compreso, avessero capito il contrario), quindi per complicarci la vita abbiamo dato un nome ad una cosa che veniva già fatta con gli hd meccanici senza che l'utente ne fosse a conoscenza e senza che avesse un nome (era implicito nella cancellazione del file).
La maggior parte delle incomprensioni deriva solo da cosa fa esattamente il trim

Il gc quindi è l'unico imputato alla effettiva cancellazione dei dati.

Grazie per i link, ora me li leggo, ma quindi per tornare all'esempio che ti avevo fatto prima del trim in prima pagina di Tennic, in quel caso che restituiva solo 0, significa che l'ssd in questione supportava il DZAT, immagino.

Tutta la mia incomprensione derivava dalla convinzione (appresa in anni di forum) che il trim cancellasse fisicamente i dati quando lanciato. Una volta appurato che non è così il fatto che sia possibile recuperare i dati non mi pare così strano visto che il tutto dipende dal gb e quindi dalla sua implementazione nel firmware che varierà a seconda del produttore e con possibilità di vari bug.
Quindi a questo punto anche l'affermazione che su ssd è più difficile recuperare i dati è vera a metà, nel senso che rispetto ai meccanici dove per non recuperare i file dovevi averci scritto sopra (anche parzialmente), quì in più hai il possibile (nel senso che non sai quando accadrà) intervento del gc.


Ripeto, strano, ma ovviamente un motivo logico ci sarà..

Il TRIM non cancella fisicamente ed il software citato
https://www.hwupgrade.it/forum/showpost.php?p=39074763&postcount=49039
può solo avere accesso alla P2P non certo alle celle fisiche.
Si tratta della lettura della mappatura con un ssd che dopo TRIM ha annullato i valori che puntano ai blocchi fisici (DRAT può anche essere, anzi, visto l'anno).

Scrivi: Quindi a questo punto anche l'affermazione che su ssd è più difficile recuperare i dati è vera a metà

Mi sembra che sia molto più vera invece. Considera che se il TRIM viene ricevuto dal controller il dato è automaticamente perso e non ci sono software in grado di riprenderlo.

PS. La rottura dell'ssd, improvvisa, paradossalmente gioca a favore, se ci pensi ai fini di un ipotetico recupero, proprio perchè è possibile recuperare integra la mappatura.




Anni fa c'era un programma per Windows, chiamato TrimCheck, che controllava il corretto funzionamento del trim analizzando il contenuto di certi settori dopo la cancellazione. Con gli SSD che ho avuto al tempo, il trim faceva immediatamente riportare zeri da parte dei settori cancellati.

Ho letto diverse volte che il TRIM non è immediato, ma messo in coda e con bassa priorità.
Ciò non vuol dire che creando un software fatto per testare il TRIM, non comporti a fine ciclo una chiamata di TRIM (lo farei anch'io dovessi creare un software del genere).

Sarebbe interessante trovare un testo tecnico sull'argomento, cosa che personalmente (cioè specifico sul trim) non ho mai trovato.


Sì esatto, e da lì l'errata convinzione che il trim cancellasse fisicamente il dato, oltre al fatto delle prime discussioni tecniche dove da sempre si diceva che il trim cancellava fisicamente.
Anche tu la sapevi così?

No, la questione di s12a è sulla tempistica di attivazione del TRIM.

frafelix
30-05-2025, 15:20
No, la questione di s12a è sulla tempistica di attivazione del TRIM.

Sì, che nel caso specifico era di qualche decina di secondi, motivo per cui davamo per scontato che il trim cancellasse fisicamente i file

Black (Wooden Law)
30-05-2025, 16:34
InnoGrit (https://www.tomshardware.com/pc-components/ssds/custom-pcie-5-0-ssd-with-3d-xl-flash-debuts-special-optane-like-flash-memory-delivers-up-to-3-5-million-random-iops) al Computex di quest'anno ha presentato un SSD a dir poco abominevole: è in formato U.2 o E3.S (stile SATA 2,5''), ha come controller l'IG5669 (PCIe 5.0 da 14 GB/s e 3,5 milioni di IOPS in lettura) ma soprattutto contiene la seconda generazione di Kioxia XL-Flash¹ che è MLC 1.600 MT/s ma che in questo SSD opera in pSLC. I tagli partono da 400GB fino a 3.200GB (3,2TB) ma la cosa più sorprendente è la durata: tenendo conto che la formula base del TBW è DWPD * capacità dell'SSD * 365 * 5 (anni di garanzia ma possono essere anche 3) questo SSD nel taglio da 3,2TB offre 292PB di TBW visto che ha un DWPD di 50. 292PB di TBW in 5 anni vuol dire 160TB al giorno.

¹: tipo di NAND flash storage class memory (SCM). SCM è un tipo di memoria che si pone tra le NAND flash e la DRAM sia come durata che come velocità. Questo tipo di NAND flash è diverso da quello "normale" visto che le pagine sono più piccole, ci sono molti più piani, ecc. SCM era anche Intel 3D XPoint e Samsung Z-NAND.

s12a
30-05-2025, 16:58
Sì esatto, e da lì l'errata convinzione che il trim cancellasse fisicamente il dato, oltre al fatto delle prime discussioni tecniche dove da sempre si diceva che il trim cancellava fisicamente.
Anche tu la sapevi così?

Sapevo che contrassegnava le celle come "da cancellare", non che le cancellasse necessariamente immediatamente. Il firmware potrebbe benissimo fare in modo che tali celle contrassegnate riportino zeri a prescindere dal fatto che contengano effettivamente dati o meno al momento della lettura.

frafelix
30-05-2025, 18:49
Che poi è quello che ha descritto Liupen con drat e dzat

@Liupen
30-05-2025, 19:40
Sì, che nel caso specifico era di qualche decina di secondi, motivo per cui davamo per scontato che il trim cancellasse fisicamente i file

Lieto allora di aver chiarito questo punto.

frafelix
30-05-2025, 23:03
Decisamente! Grazie come sempre

giovanni69
30-05-2025, 23:34
@Black (Wooden Law)

..stupefacente? :confused:

@Liupen
01-06-2025, 15:26
Black ho terminato le mie ricerche sul Samsung 850 PRO e le V-Nand 32L.

Le Nand V2 di tipo MLC a 2 bit sono state fatte da Samsung che però non ha mai specificato 2 bit ma sempre chiamate "MLC" mentre le TLC le chiamava "MLC 3 bit".
Ho seguito la sequenza di annunci di uscita e produzione sia degli ssd che delle celle e c'è un filo logico che porta in sequenza: 24L - 32L - 32L 3bit - 48L 3 bit ecc

Il Samsung 850 PRO dei sample delle prime review adottavano appunto la prima serie V2 MLC (2 bit).Si arrivava fino ad 1 TB di capienza ssd.
La densità del die e i teardown sono convincenti.
Le schede di TPU sono sbagliate.
A partire dall'uscita del taglio di ssd da 2TB, le V-Nand MLC (2 bit) Samsung sono state aggiornate, divenendo simili alle V-Nand 32L a 3 bit, ma sempre 2 bit sono, anche se non si può esserne sicuri poiché non c'è un analisi (solo sulle 3 bit). In questo caso il fatto che siano MLC 2 bit è deduttivo*

* deduttivo inteso come semplice: se ho un ssd 850 PRO e un 850 EVO da 2TB in confronto tra loro (se ne sono parecchie recensioni di questo parallelo) che hanno apparentemente le stesse Nand Flash (stessa morfologia, densità, area) con 8 pacchetti sul pcb ciascun ssd, è logico deduttivo pensare che se sul 850 PRO le celle siano emulate, il taglio dell'ssd non può raggiungere i 2TB. Ragionamento che non fà una piega. PS. da sapere che l'emulazione avviene a livello di controller non di cella.

Se siete interessati ad un bel PDF di 25 pagine che ho fatto man mano che prendevo appunti... ce l'ho! Ahahah!!!

Black (Wooden Law)
01-06-2025, 19:46
PS. da sapere che l'emulazione avviene a livello di controller non di cella.

Sì ovvio, anche perché per trasformare delle NAND flash TLC a delle “MLC” dovresti modificare fisicamente il quantitativo di pagine, blocchi e le loro dimensioni, quindi dovresti far passare fisicamente delle pagine da 16kB a 8kB mentre con pMLC le pagine rimangono 16kB ma hanno semplicemente un bit in meno all’interno.
Se siete interessati ad un bel PDF di 25 pagine che ho fatto man mano che prendevo appunti... ce l'ho! Ahahah!!!

Posta Liupen, o al massimo mandamelo in privato in caso non potessi qui.

Mi piace la tua analisi comunque, solo che non capisco il tuo “divenendo simili alle V-Nand 32L a 3 bit”. O sono delle V2 MLC o delle V2 TLC, non ci sono vie di mezzo (penso, poi magari mi sbaglio).

Per aggiungere, comunque, mi son dimenticato di riportare quello che dice lo spreadsheet cinese (https://docs.google.com/spreadsheets/u/0/d/1QiG1B7K37fNBtELS4Ug3_XV4A1x_vi-ALx1jgA076yc/htmlview?pli=1#) (genio, ma non viene aggiornato da un anno quindi non mi è passato di mente dal momento che non lo uso da un po’. Peccato che non venga aggiornato perché è supercompleto). Se vai all’850 PRO vedi che usa un mix di V1 (mai viste però, magari solo le prime versioni o vecchissimi rumor), V2 MLC, V2 pMLC (quindi TLC) e addirittura V3 MLC (anche se non l’ho mai viste)

@Liupen
02-06-2025, 02:54
Sì ovvio, anche perché per trasformare delle NAND flash TLC a delle “MLC” dovresti modificare fisicamente il quantitativo di pagine, blocchi e le loro dimensioni, quindi dovresti far passare fisicamente delle pagine da 16kB a 8kB mentre con pMLC le pagine rimangono 16kB ma hanno semplicemente ub bit in meno all’interno.


Posta Liupen, o al massimo mandamelo in privato in caso non potessi qui.

Mi piace la tua analisi comunque, solo che non capisco il tuo “divenendo simili alle V-Nand 32L a 3 bit”. O sono delle V2 MLC o delle V2 TLC, non ci sono vie di mezzo (penso, poi magari mi sbaglio).

Per aggiungere, comunque, mi son dimenticato di riportare quello che dice lo spreadsheet cinese (https://docs.google.com/spreadsheets/u/0/d/1QiG1B7K37fNBtELS4Ug3_XV4A1x_vi-ALx1jgA076yc/htmlview?pli=1#) (genio, ma non viene aggiornato da un anno quindi non mi è passato di mente dal momento che non lo uso da un po’. Peccato che non venga aggiornato perché è supercompleto). Se vai all’850 PRO vedi che usa un mix di V1 (mai viste però, magari solo le prime versioni o vecchissimi rumor), V2 MLC, V2 pMLC (quindi TLC) e addirittura V3 MLC (anche se non l’ho mai viste)


https://drive.google.com/file/d/1-o3evhsUyR8tCAwgDG57jgVSSzZOpVtJ/view?usp=sharing

L'ho caricato su google drive (si deve avere un account google).

Ci ho passato un po' a metterlo apposto, farlo un minimo scorrevole e pure con la copertina :sofico:

Il “divenendo simili alle V-Nand 32L a 3 bit” lo capirai leggendo :Prrr:

spreadsheet cinese non so se ha fatto bene i compiti... in realtà ho visto un altro blog cinese sempre che parla di Samsung pMLC, ma poi degli esempi concreti non ne fanno, quindi come verifichi? Non sarò uno scienziato, ma almeno un "vedi quà, il part number delle celle, un seriale di ssd..." niente, scrivono solo opinioni.

V1 sono le 24L le prime V-Nand (solo 2bit)
V2 le 32L (2 bit e 3 bit)
V3 le 48L (2 bit esempio: SM961 e 3 bit)
...
...

Buona lettura!

andreag8
02-06-2025, 13:48
Per prima cosa grazie a chi ha mantenuto e mantiene aggiornato il thread.

Cerco SSD da 2/4TB.
Domanda: a parità di prezzo meglio Samsung 990 Pro o WD Black SN850X? (Si ho letto la prima pagina :fagiano: )
Come mai non viene consigliato il Samsung?

Black (Wooden Law)
02-06-2025, 14:17
Per prima cosa grazie a chi ha mantenuto e mantiene aggiornato il thread.

Cerco SSD da 2/4TB.
Domanda: a parità di prezzo meglio Samsung 990 Pro o WD Black SN850X? (Si ho letto la prima pagina :fagiano: )
Come mai non viene consigliato il Samsung?

Meglio l’SN850X IMHO, semplicemente per le migliori performance (anche se di poco). Con il 990 PRO hai un drive più duraturo sulla carta ma anche qui di poco¹ vista l’ottima qualità dell’SN850X, quindi per me SN850X tutta la vita dato il prezzo più basso (specialmente nel taglio da 4TB).

¹: aggiungo, oltretutto, che con una probabilità del 99% non andrai mai a rompere un 990 PRO o un SN850X per le scritture, specialmente a tagli così grandi dove la durata in termini di scritture assolute viene amplificata.

Black (Wooden Law)
04-06-2025, 00:47
@Liupen solo oggi ho avuto il tempo sia di spulciarmi per bene il tuo PDF (ben fatto ovviamente, complimenti) che di elaborare una risposta. Quando l'hai postato gli ho soltanto dato un'occhiata molto velocemente e gli altri giorni ero impegnato quindi purtroppo non ho potuto risponderti subito, mi scuso infatti del ritardo della risposta che ti sto dando.

Suddivido il tuo PDF in tre parti:
1. esistenza delle V2 MLC;
2. confronto tra "Samsung 2nd Gen 86Gbit 40nm MLC V-NAND" e "K9ADGD8S0A";
3. V2 MLC nel sample di AnandTech.

Prima parte
Sulla prima parte non ho nulla da dirti, mi sono scappate quelle immagini che provano l'esistenza delle V2 MLC. Non avendo nulla da contestare passo direttamente alle altre due parti:

Seconda parte
Prima di dirti il perché del confronto che hai fatto tra "Samsung 2nd Gen 86Gbit 40nm MLC V-NAND" e "K9ADGD8S0A" è sbagliato ti voglio far notare che il NAND flash decoder che hai preso per questo PDF è del 2009 (o perlomeno nel 2009 ci è stato l'ultimo aggiornamento) e in quell'anno le NAND flash 3D di Samsung erano ben lontane dall'essere commercializzate. Questo non vuol dire che tutte le informazioni che contiene sono errate, perché come puoi ben vedere nel decoder delle NAND flash di Samsung dello spreadsheet cinese (che ritengo essere di gran lunga migliore visto che l'ultimo aggiornamento dello spreadsheet risale al 2024) alcuni parametri sono giusti, semplicemente alcune cose non hanno molto senso.

La prima cosa che non ha senso è la quarta unità del S/N, "Density". Perché si ferma a massimo 512Gb se abbiamo tagli fino a 16.384Gb secondo lo spreadsheet cinese? come hai ottenuto che "SG" corrisponde a 1.365Gb (anche se nello spreadsheet cinese sotto la categoria "V2 pMLC Density" c'è scritto 1.376Gb ma bene o male sono la stessa cosa) se non c'è in quel decoder?

Seconda cosa: sesta unità, "Technology". Come hai ottenuto che "Y" corrisponde a Toggle 2.0 se lì non c'è scritto niente? La prima versione di Toggle è uscita nel 2007 ma in quel decoder sembra che non esiste.

Terza cosa che non ha senso: decima unità, "Generation". Sappiamo che le NAND flash 3D di Samsung si dividono da V1 a V9 per ora (anche se le V9 non sono ancora state commercializzate), cos'è prima, seconda, terza, quarta, quinta, sesta, venticinquesima e ventiseiesima generazione? cosa mi rappresentano? Assolutamente nulla, perlomeno dette così. Nel package "K9USGY8S7M" la "M" corrisponde a "1st generation", ma prima generazione di cosa? prima generazione di NAND flash 3D? No, perché nello spreadsheet cinese la "M" corrisponde alle pMLC V2 32L e perché come già detto prima nel 2009 le NAND flash 3D di Samsung non esistevano.

Nello spreadsheet cinese ci sono una tonnellata di caselle in più che si dividono in SLC, MLC, TLC e QLC con alcune sottocategorie come "pSLC", "pMLC", "SDR" e "DDR", ecc. Magari quel "Generation" ha senso per le NAND flash planari che avevano diversi nodi e quindi diverse generazioni (sappiamo che Samsung è arrivata fino a 14 nm con le NAND flash 2D ma che è partita con un nodo di 90 nm, quindi ci sono state un sacco di generazioni in mezzo) ma sicuramente non per le NAND flash 3D che arrivano fino a V9 e basta (delle V10 si è fatto un accenno su quanti layer avrà e basta).

Quarta e ultima cosa che non ha senso: "NAND Flash Code Information(2/3)" quindi tutte le unità da 11 a 18. Prima cosa non hanno senso le 18 unità totali visto che le NAND flash 3D usate sull'850 PRO (ma anche su tutti gli altri SSD Samsung con NAND flash 3D) hanno 15 caratteri contando anche il trattino, poi c'è il problema della mancanza di informazioni che quel decoder ha rispetto allo spreadsheet cinese.
------------------------------------------------------------------------------------------------------------------------------
Ora, parlando effettivamente del confronto "Samsung 2nd Gen 86Gbit 40nm MLC V-NAND" e "K9ADGD8S0A" ti dico che c'è qualcosa che non torna con le fonti e che smentiscono le tue conclusioni, ossia che il primo die ha una dimensione di 87,4 mm² mentre il secondo una dimensione di 68,9 mm² comportando al fatto che i die non sono uguali.

Il problema alla base è che tanti articoli non hanno distinto la differenza tra la dimensione del die e la dimensione dell'array NAND flash (cosa che adesso non capita più visto che si parla sempre di dimensione del die e basta). Con "dimensione del die" si intende tutto ciò che si trova all'interno del die: tutti i piani, il pager buffer, il circuito periferico e tutto il resto mentre con "dimensione dell'array NAND flash" si intende soltanto la dimensione di un piano, o perlomeno questo è quello intende Jeongdong Choe nell'articolo di EE Times:
L'area del die 32L V-NAND è di 84,3 mm²
E
L'area dell'array della memoria NAND è aumentato da 48,9 mm² a 68,7 mm² che è il 40,3% più largo.

So che Samsung nel suo ISSCC dice "die size" ma a questo punto deve sbagliarsi, o semplicemente ha scritto "die size" quanto intende dire la dimensione di un piano. So che Samsung è Samsung ma letteralmente Jeongdong Choe ha scoperchiato un package per prendere le misure, non posso fidarmi meno di lui sinceramente...

Oltretutto, il die "K9ADGD8S0A" (trovato all'interno del package "K9HQGY8S5M e K9LPGY8S1M" dove S5M si trova fino all'850 PRO 1TB) secondo lo spreadsheet cinese è TLC V2 ed è stato trovato nell'850 PRO da 128GB da TechInsights (https://www.techinsights.com/products/sar-1407-802?utm_source=direct&utm_medium=website). Se veramente le dimensioni del die fossero diverse e non ci fosse la possibilità di emulare "K9ADGD8S0A" in pMLC vorrebbe dire che questo die non esisterebbe nell'850 PRO ma nell'850 EVO perché sarebbe rimasto TLC a vita.

Terza parte
Parlando dell'ultima parte, anche qui non ho molto da dire. Il package di AnandTech è interamente "K9UMGB8S7A" ossia che tutti gli 8 package hanno questo S/N e non c'è un mix come per i tagli più piccoli. La "U" come terzo carattere afferma che le NAND flash sono puramente MLC, vero, e questo ce lo conferma proprio lo spreadsheet cinese, ma questa cosa che il sample di AnandTech abbia le V2 MLC concorda sempre con lo spreadsheet cinese che include queste NAND flash (lui le include per il controller MEX ma è probabile che tra tutte queste versioni di package qualcosa sia scappato) nella casella dell'850 PRO.

Conclusioni
1. secondo l'articolo di EE Times fatto da Jeongdong Choe sia il die "Samsung 2nd Gen 86Gbit 40nm MLC V-NAND" che "K9ADGD8S0A" hanno la stessa dimensione dell'array NAND flash di 68,7 mm²;
2. tutti i package dell'850 PRO che finiscono con "S5M" e "S1M" contengono all'interno il die "K9UMGB8S7A" che secondo lo spreadsheet cinese (decoder più aggiornato finora) è V2 TLC, ciò vuol dire che tutti gli 850 PRO con questo package e questo die hanno NAND flash pMLC;
3. AnandTech e lo spreadsheet cinese confermano il fatto che alcuni modelli (teoricamente quelli più recenti) hanno NAND flash MLC native (sempre V2 ovviamente);
4. non sappiamo qual è il die all'interno del package "K9USGY8S7M" che è condiviso con il package "K9HQGY8S5M" ma secondo lo spreadsheet cinese "SG" è una densità delle NAND flash pMLC e "M" è una generazione del die sempre pMLC. Tenendo conto che non ha senso senso usare metà package con die MLC nativi e metà package con die pMLC, direi che anche i package "K9USGY8S7M" al loro interno contengono die pMLC.

andreag8
04-06-2025, 08:05
Meglio l’SN850X IMHO, semplicemente per le migliori performance (anche se di poco). Con il 990 PRO hai un drive più duraturo sulla carta ma anche qui di poco¹ vista l’ottima qualità dell’SN850X, quindi per me SN850X tutta la vita dato il prezzo più basso (specialmente nel taglio da 4TB).
Il prezzo non è determinante nel mio caso, dato che per il momento sto valutando quelli di seconda mano e lì i prezzi sono pressoché identici.

Due domande:
Il 990 Pro non viene consigliato in prima pagina perché ha un rapporto prezzo/prestazioni inferiore ad altri modelli o c'è qualche altro motivo?
Per quanto riguarda il software di gestione che forniscono i produttori c'è differenza tra Samsung e WD? Personalmente ho esperienza solo con il Magician.

unnilennium
04-06-2025, 09:31
Premettendo che non sono esperto, però i driver Samsung al netto dell'hype non sono più i più prestazionali, quindi anche a parità di prezzo a parte i soliti youtuber, non vengono consigliati. I software di gestione sono simili tra loro, la cosa più importante è l'aggiornamento eventuale del firmware, per il resto che ci sia o meno poco cambia... Detto questo, se ti piace Samsung vai tranquillo. Io comunque ho un wd nel notebook e funziona molto bene, niente da dire.

Inviato dal mio 23127PN0CG utilizzando Tapatalk

Black (Wooden Law)
04-06-2025, 10:57
Il 990 Pro non viene consigliato in prima pagina perché ha un rapporto prezzo/prestazioni inferiore ad altri modelli o c'è qualche altro motivo?

Sì e anche per le performance leggermente migliori (secondo me). Primariamente l’SN850X ha una cache SLC molto più grande (600GB vs. 240GB) e poi secondariamente fa qualcosa in più sia in lettura sequenziale (600 MB/s, poco, molto poco) che in scrittura randomica (~20.000 IOPS in più). La cosa che potresti notare di più è sicuramente la cache SLC più grande in un trasferimento di file, gli altri due punti poco e nulla.
Per quanto riguarda il software di gestione che forniscono i produttori c'è differenza tra Samsung e WD? Personalmente ho esperienza solo con il Magician.

Non lo so, non ho esperienza con nessuno dei sue software ma non ho mai sentito lamentele né di Magician né del software di WD.
Premettendo che non sono esperto, però i driver Samsung al netto dell'hype non sono più i più prestazionali, quindi anche a parità di prezzo a parte i soliti youtuber, non vengono consigliati. I software di gestione sono simili tra loro, la cosa più importante è l'aggiornamento eventuale del firmware, per il resto che ci sia o meno poco cambia... Detto questo, se ti piace Samsung vai tranquillo. Io comunque ho un wd nel notebook e funziona molto bene, niente da dire.

Concordo.

@Liupen
04-06-2025, 22:19
Al lavoro ho letto veloce e non vedevo l'ora che fosse dopo cena per sedermi al pc e scrivere. :banned: :asd:


Conclusioni
1. secondo l'articolo di EE Times fatto da Jeongdong Choe sia il die "Samsung 2nd Gen 86Gbit 40nm MLC V-NAND" che "K9ADGD8S0A" hanno la stessa dimensione dell'array NAND flash di 68,7 mm²;
2. tutti i package dell'850 PRO che finiscono con "S5M" e "S1M" contengono all'interno il die "K9UMGB8S7A" che secondo lo spreadsheet cinese (decoder più aggiornato finora) è V2 TLC, ciò vuol dire che tutti gli 850 PRO con questo package e questo die hanno NAND flash pMLC;
3. AnandTech e lo spreadsheet cinese confermano il fatto che alcuni modelli (teoricamente quelli più recenti) hanno NAND flash MLC native (sempre V2 ovviamente);
4. non sappiamo qual è il die all'interno del package "K9USGY8S7M" che è condiviso con il package "K9HQGY8S5M" ma secondo lo spreadsheet cinese "SG" è una densità delle NAND flash pMLC e "M" è una generazione del die sempre pMLC. Tenendo conto che non ha senso senso usare metà package con die MLC nativi e metà package con die pMLC, direi che anche i package "K9USGY8S7M" al loro interno contengono die pMLC.


Ok, ho capito che di quel DB cinese ne hai fatto una specie di bibbia.


Iniziamo dalle tue conclusioni:

Scrivi: 1. secondo l'articolo di EE Times fatto da Jeongdong Choe sia il die "Samsung 2nd Gen 86Gbit 40nm MLC V-NAND" che "K9ADGD8S0A" hanno la stessa dimensione dell'array NAND flash di 68,7 mm²;

Era meglio che riportassi anche la fonte. Vediamo se riesco a comprendere.

Stiamo parlando che il (ora esistente :Prrr: ) V-Nand V2 32L MLC 2-bit con die da 86 Gbit ha la stessa dimensione in nanometriquadrati (quindi area occupata) della V-Nand V2 32L MLC 3-bit da 128 Gbit?

No, sbagli... che poi è sbagliato dire che uno sbaglia, ci stiamo semplicemente confrontando su dati che si trovano sul web, per cui uno può vedere o accorgersi di qualcosa che sfugge ad un altro, quindi senza fretta Black, l'importante è far chiarezza.

Andrew Walker quì https://www.3dincites.com/2014/12/samsungs-3d-v-nand-flash-product-ceaselessly-marching/ e riportato a pag. 12 del mio pdf
commenta i dati di analisi SEM di Techinsights (io non ho accesso diretto all'analisi, serve l'abbonamento) e scrive:

Ma diamo prima un'occhiata a ciò che Techinsights ha fornito. La Figura 2 mostra il die con una barra di misurazione che ci permette di ottenere quanto segue: dimensione del die = 87,4 mm²; efficienza dell'array = 66%.

FIGURA 2 – Foto del die della V-NAND di seconda generazione a 32 strati e 86 Gbit di Samsung (per gentile concessione di Techinsights).
Figura 2: Foto del die della V-NAND di seconda generazione a 32 strati e 86 Gbit di Samsung (per gentile concessione di Techinsights ).

Mettiamo che sia questo https://borecraft.com/PDF/Technical%20Digests/128Gb_3b_VNAND.pdf (gennaio 2016)
e questo https://www.eetimes.com/samsungs-3d-v-nand-32l-vs-48l-just-vertical-expansion/#google_vignette (giugno 2016)

il documento/i su cui ti basi

A 128 Gb 3b/cell V-NAND Flash Memory With 1 Gb/s I/O Rate - analizza la V2 MLC a 3-bit e già nell'abstract riporta la dimensione che citi 68,7 mm²
Idem Jeongdong Choe nell'altro scritto dove si comparano le precedenti 3-bit 32L con addirittura le V3 (48L) per cui:
V2 TLC = 84,3 mm²
V3 TLC = 99,8 mm² , con un aumento del 17,3% dovuto alla maggiore lunghezza del die

Aggiungo, per completezza di informazione che da un documento ISSCC 2014 " Memoria Flash NAND verticale MLC tridimensionale da 128 Gb con strati impilati a 24 WL e programmazione ad alta velocità da 50 MB/s ", la prima versione 24L è di 133 mm².


Sembra che ogni tecnologia porti ad una dimensione d'area diversa.

La risposta alla fine è che la stessa dimensione dell'array NAND flash di 68,7 mm² c'è l'hanno le V-Nand 32L da 128Gbit sia 2-bit che a 3-bit perchè frutto dello stesso processo produttivo.


Scrivi: 2. tutti i package dell'850 PRO che finiscono con "S5M" e "S1M" contengono all'interno il die "K9UMGB8S7A" che secondo lo spreadsheet cinese (decoder più aggiornato finora) è V2 TLC, ciò vuol dire che tutti gli 850 PRO con questo package e questo die hanno NAND flash pMLC;

Crediamo ai cinesi, che ti devo dire!!

Uno stack è composto di die, e il die è fatto in quel modo, se Samsung lo cataloga:
K9UMGB8S7A sono i die dentro il Samsung 850 2TB analizzati a pag. 18 del mio pdf

Come vedi è una seconda versione delle V2 32L fatte con die da 128Gbit
Come detto da Anandtech quì: https://www.anandtech.com/show/9451/the-2tb-samsung-850-pro-evo-ssd-review
Oltre al nuovo controller MHX, c'è un'altra modifica hardware: il codice prodotto NAND suggerisce che l'850 Pro da 2 TB utilizza die da 128 Gbit invece di quelli da 86 Gbit presenti nelle altre capacità.


Questa versione da 128Gbit (che, tanto per riallacciarsi al tuo precedente punto 1, ha area uguale a 84,3 mm²) compone un package uguale a quello della versione a 3-bit (come leggi dall'articolo di Anandtech). Uguali, stessa superficie e numero di die e capienza dello stack pari a 2Tbit (vedi il 4° e 5° carattere UGUALE del NAND Flash
Code Information Samsung).
Solo che il chip sul 850 PRO è a 2-bit. Il chip sul 850 EVO e a 3-bit
Tutti e due gli ssd hanno 8 chip (8 package)
OK?

Cosa vuol dire questo?

Vuol dire che non basta prendere il chip presente sull'850 EVO e dire al controller di emulare le nand in 2-bit, perchè così facendo dovrei, per raggiungere i 2TB di ssd), mettere almeno 3 chip in più sul pcb. Questo perchè un die da 128Gbit 3-bit emulato pMLC conterrebbe (-33%) SOLO 86 Gbit e non basterebbero:
16 die per stack = 86 Gbit x 16 = 1376 Gbit
8 stack per ssd = 8 x 1376 = 11008 Gbit = 1TB non 2TB

Spero ora sia chiaro il ragionamento espresso a pag 19 del pdf.

Quindi NO, non sono V2 TLC.


Scrivi: 3. AnandTech e lo spreadsheet cinese confermano il fatto che alcuni modelli (teoricamente quelli più recenti) hanno NAND flash MLC native (sempre V2 ovviamente);

E' ci mancherebbe altro!
Altro che esistono, gli 850 PRO SONO con MLC 2-bit NATIVE!!!!

Scrivi: 4. non sappiamo qual è il die all'interno del package "K9USGY8S7M" che è condiviso con il package "K9HQGY8S5M" ma secondo lo spreadsheet cinese "SG" è una densità delle NAND flash pMLC e "M" è una generazione del die sempre pMLC.


Ma no, perchè?!!
Guarda che ci arrivi facilmente, ed in almeno 2 modi logici:

1)
Esempio: https://www.thessdreview.com/our-reviews/samsung-850-pro-ssd-review-showing-3d-v-nand/

La recensione è del 1 luglio 2014 (la presentazione dell850 PRO), e se vai a vedere pag. 3 e 4 del mio pdf, la presentazione delle V-Nand V2 32L a 3-bit è ad Agosto che viene annunciata ed è del 9 ottobre 2014 l'annuncio Samsung dell'inizio produzione in serie di questa memoria.
Ergo, all'uscita degli 850 PRO non esistevano le memorie V-Nand TLC che tu vorresti emulare per far stare nell'850 PRO.

2)
sempre: https://www.thessdreview.com/our-reviews/samsung-850-pro-ssd-review-showing-3d-v-nand/

K9USGY8S7M + K9PRGY8S5M = 1 TB SSD

Metti che non hai il dato SG e RG (anche se alcune recensioni ti mettono cosa sono) o trovi Samsung Nand Code aggiornati da utenti (cinesi :asd: ). Ma metti che non hai la Densità (come viene chiamata).

K9USGY8S7M: hai U che vuol dire "MLC 16 DIE STACK" ed hai ovviamente che ogni Die è da 86 Gbit (vedi i discorsi triti e ritriti sopra.
16 x 85,xx Gbit = 13xx Gbit ogni pacchetto

Idem per il pacchetto K9PRGY8S5M: hai P che vuol dire MLC ODP (Octa die package)...

Insomma non ci va poi tanto a trovare, sapendo che l'ssd da 1 TB ha 8 pacchetti, 4 di un tipo e 4 di un altro che:

16 x 86 GBit = 1 3xx Gbit per pacchetto --> 170 GB x 4 = 680 GB
8 x 86 GBit = 68x Gbit per pacchetto --> 85 GB x 4 = 340 GB
Somma: 1020 GB

Scrivi: Tenendo conto che non ha senso senso usare metà package con die MLC nativi e metà package con die pMLC, direi che anche i package "K9USGY8S7M" al loro interno contengono die pMLC.

Perchè non ha senso cosa hai scritto..
1 - come fai a emulare qualcosa che ancora non è stato prodotto?
Dovresti parlare ad esempio del K9UMGB8S7A che ne avrebbe le potenzialità essendo con die da 128Gbit e della stessa generazione di un MLC 3-bit.
2 - come fai a emulare un pacchetto V-Nand di cui conosci la densità totale (Gbit) e da che taglio sono gli ssd che li montano, che è incompatibile con l'uso in pMLC?



La prima cosa che non ha senso è la quarta unità del S/N, "Density". Perché si ferma a massimo 512Gb se abbiamo tagli fino a 16.384Gb secondo lo spreadsheet cinese? come hai ottenuto che "SG" corrisponde a 1.365Gb (anche se nello spreadsheet cinese sotto la categoria "V2 pMLC Density" c'è scritto 1.376Gb ma bene o male sono la stessa cosa) se non c'è in quel decoder?


Come fà invece lo spreadsheet cinese a conoscere da quanto sono le densità dei flash Samsung?
Io non vedo un documento Samsung, vedo una tabella.
Chi ti dice che quello che stà scritto è vero?

Come mai Black non mi credi e credi ad una tabella cinese anonima?
Non sono forse più il tuo simpatico Liupen di quartiere e ispiratore della tua passione per gli ssd?

Guarda ti dirò una cosa che ti farà cambiare idea all'istante sull'attendibilità di quel database (https://docs.google.com/spreadsheets/u/0/d/1QiG1B7K37fNBtELS4Ug3_XV4A1x_vi-ALx1jgA076yc/htmlview?pli=1#)

Questo è il teardown della prima serie di V-Nand 32L 86 Gbit fatto da TechInsights (SEM datati luglio-agosto 2014)
https://i.ibb.co/mrF9pg5V/Cattura10.png (https://ibb.co/rKfx9N2R)
come leggi si tratta del package K9HQGY8S5M

Ebbene, indovina un po QG (la densità di 341 Gbit) dove è stata catalogata?
Eh, pMLC!
Ma possibile!?!
Mi viene l'ulcera solo a pensarci.

L'unica 32L MLC 2-bit analizzata in ogni micron, il prototipo, la prima... è loro la catalogano pMLC, quindi TLC.

FAIL!!!
Ma di brutto...



Seconda cosa: sesta unità, "Technology". Come hai ottenuto che "Y" corrisponde a Toggle 2.0 se lì non c'è scritto niente? La prima versione di Toggle è uscita nel 2007 ma in quel decoder sembra che non esiste.


Si.

Y è Toggle 2.0
B e D dovrebbero entrambi riferirsi a Toggle 3.0

Guarda tutti i pacchetti associati a cache DDR 2.0 e vedi che sono nominati Y



Terza cosa che non ha senso: decima unità, "Generation". Sappiamo che le NAND flash 3D di Samsung si dividono da V1 a V9 per ora (anche se le V9 non sono ancora state commercializzate), cos'è prima, seconda, terza, quarta, quinta, sesta, venticinquesima e ventiseiesima generazione? cosa mi rappresentano? Assolutamente nulla, perlomeno dette così. Nel package "K9USGY8S7M" la "M" corrisponde a "1st generation", ma prima generazione di cosa? prima generazione di NAND flash 3D? No, perché nello spreadsheet cinese la "M" corrisponde alle pMLC V2 32L e perché come già detto prima nel 2009 le NAND flash 3D di Samsung non esistevano.


Il decimo carattere del codice penso sia un "codice" di sviluppo Samsung che non sempre ha senso, ma quasi sempre.

Comunque non ti confondere con V1, V2, V3, ecc è definita da Samsung come generazione generale di V-Nand, quindi 24L, 32L, 48L. 64, 96L ecc.
Quell'altra del codice dei pacchetti è appunto riferita alla generazione di pacchetto di uno stesso tipo.

Tipo, per farti un esempio:
K90MGY8S7M - questa è la 1a generazione della 32L a 3-bit (infatti è M). Questo pacchetto si trova nelle prime recensioni del Samsung 850 EVO
K90MGB8S7C - l'anno dopo all'uscita di un nuovo taglio di ssd si passa alla 4a generazione di pacchetto sempre32L a 3-bit da 256 GB ma di una produzione/fabbrica/lavorazione, ecc ecc, diversa.




Quarta e ultima cosa che non ha senso: "NAND Flash Code Information(2/3)" quindi tutte le unità da 11 a 18. Prima cosa non hanno senso le 18 unità totali visto che le NAND flash 3D usate sull'850 PRO (ma anche su tutti gli altri SSD Samsung con NAND flash 3D) hanno 15 caratteri contando anche il trattino, poi c'è il problema della mancanza di informazioni che quel decoder ha rispetto allo spreadsheet cinese.

Assolutamente, anche oggi sono 15 caratteri
Esempio sul Samsung 990 PRO (review THW)
K9DVGY8JRD-DCK0
Il problema è oggi che non abbiamo più la pappa fatta, non nel 2014 quando il documento Nand Flash Code information si trova anche aggiornato fino al 2016.
Ora bisogna andare a leggere fra le righe ed essere attenti:
"The flash packages are labeled K9DVGY8JRD-DCK0 which denotes that it is Samsung’s 176-layer TLC NAND. With the 2TB SKU, this flash has 512Gb dies as indicated by “V” - although the upcoming 4TB may require 1Tb “X” dies. "




Ora, parlando effettivamente del confronto "Samsung 2nd Gen 86Gbit 40nm MLC V-NAND" e "K9ADGD8S0A" ti dico che c'è qualcosa che non torna con le fonti e che smentiscono le tue conclusioni, ossia che il primo die ha una dimensione di 87,4 mm² mentre il secondo una dimensione di 68,9 mm² comportando al fatto che i die non sono uguali.

Il problema alla base è che tanti articoli non hanno distinto la differenza tra la dimensione del die e la dimensione dell'array NAND flash (cosa che adesso non capita più visto che si parla sempre di dimensione del die e basta). Con "dimensione del die" si intende tutto ciò che si trova all'interno del die: tutti i piani, il pager buffer, il circuito periferico e tutto il resto mentre con "dimensione dell'array NAND flash" si intende soltanto la dimensione di un piano, o perlomeno questo è quello intende Jeongdong Choe nell'articolo di EE Times:

E


So che Samsung nel suo ISSCC dice "die size" ma a questo punto deve sbagliarsi, o semplicemente ha scritto "die size" quanto intende dire la dimensione di un piano. So che Samsung è Samsung ma letteralmente Jeongdong Choe ha scoperchiato un package per prendere le misure, non posso fidarmi meno di lui sinceramente...

Oltretutto, il die "K9ADGD8S0A" (trovato all'interno del package "K9HQGY8S5M e K9LPGY8S1M" dove S5M si trova fino all'850 PRO 1TB) secondo lo spreadsheet cinese è TLC V2 ed è stato trovato nell'850 PRO da 128GB da TechInsights (https://www.techinsights.com/products/sar-1407-802?utm_source=direct&utm_medium=website). Se veramente le dimensioni del die fossero diverse e non ci fosse la possibilità di emulare "K9ADGD8S0A" in pMLC vorrebbe dire che questo die non esisterebbe nell'850 PRO ma nell'850 EVO perché sarebbe rimasto TLC a vita.

Riguardo questo, penso di averti chiarito già sopra
Sono due momenti, due tipi di pacchetti caratterizzati da una dimensione della die diversa.




Terza parte
Parlando dell'ultima parte, anche qui non ho molto da dire. Il package di AnandTech è interamente "K9UMGB8S7A" ossia che tutti gli 8 package hanno questo S/N e non c'è un mix come per i tagli più piccoli. La "U" come terzo carattere afferma che le NAND flash sono puramente MLC, vero, e questo ce lo conferma proprio lo spreadsheet cinese, ma questa cosa che il sample di AnandTech abbia le V2 MLC concorda sempre con lo spreadsheet cinese che include queste NAND flash (lui le include per il controller MEX ma è probabile che tra tutte queste versioni di package qualcosa sia scappato) nella casella dell'850 PRO.


La terza parte del mio pdf riguarda lo smentire che la V-Nand V2 32L a 3-bit del Samsung 850 EVO sia poi la stessa che poi di ci emulata nel 850 PRO (o meglio pensi che sia perchè visto nel DB cinese).
Anche di questo te ne ho già scritto sopra.

Boh! E' tutto.
Se hai ancora dubbi scrivi che ne parliamo.
In realtà non è neanche importante la correzione del DB di TPU, mi interessa più spiegare e costringerti a mettere in dubbio le fonti... tutte no, io sono Liupen. Ahahah!
Almeno non ho fatto le 3 di notte stavolta.

DOC-BROWN
05-06-2025, 12:16
per voi mega esperti ....


ho appena visto la pubblicita' 2025 di una NUOVA scheda SD Speed 9.1 ?


sembra sia una novita' del 2025 , cioe ? e utilizzano le memorie NAND
anche queste schedine di memorie o?

frafelix
05-06-2025, 12:35
In realtà praticamente tutti i supporti di memoria usano le nand, dalle usb alle schedine sd, la differenza principale è che non hanno un controller come negli ssd e le nand non sono di prima scelta di solito

Black (Wooden Law)
05-06-2025, 13:10
Ok, ho capito che di quel DB cinese ne hai fatto una specie di bibbia.

No Liupen, non è la bibbia per me, semplicemente è lo spreadsheet più completo e informativo che ci sia in giro e non vedo il motivo per il quale debba essere inaffidabile. Capisco che qualche cosa possa esser sbagliata ma non ho i mezzi per dire che il decoder di Samsung (come quello degli altri produttori) sia errato. Personalmente ho usato quello degli altri produttori (specialmente quello di YMTC) e devo dire che tutti i parametri ritornano con quello che il FID di VLO mostra per ogni scansione. Quindi ripeto, non posso dire che è inaffidabile.

Fai comunque conto che diverse informazioni nel DB di TPU son prese da lì. Non dico che è una bibbia ma è sicuramente un'eccellente fonte visto che ha anche tanti drive di cui non si trova facilmente l'hardware.
La risposta alla fine è che la stessa dimensione dell'array NAND flash di 68,7 mm² c'è l'hanno le V-Nand 32L da 128Gbit sia 2-bit che a 3-bit perchè frutto dello stesso processo produttivo.

E dove sbaglio allora scusami? Mi sembra che siamo d'accordo su questa cosa. Gli altri articoli scrivono che il die da 86Gb ha una dimensione del die di circa 87,4 mm² e Jeongdong Choe scrive uguale (84,3 mm² ma siamo lì), soltanto che aggiunge anche le dimensione dell'array NAND flash che è appunto 68,7 mm². Se alla fine i die TLC hanno queste dimensioni degli array e del die mi viene da pensare che vengano usati in pMLC visto che appunto le dimensiono sono uguali e la capacità in pMLC viene ridotta a 86Gb.
Scrivi: 2. tutti i package dell'850 PRO che finiscono con "S5M" e "S1M" contengono all'interno il die "K9UMGB8S7A" che secondo lo spreadsheet cinese (decoder più aggiornato finora) è V2 TLC, ciò vuol dire che tutti gli 850 PRO con questo package e questo die hanno NAND flash pMLC;

Qui in realtà ho sbagliato Liupen e ti chiedo scusa, tra tutti questi S/N mi son confuso e ho fatto un mix. Quello che volevo dire è che tutti i package che per l'850 PRO finiscono con "S5M" e "S1M" - dove i primi sono contenuti in tutti gli SSD dal 128GB all'1TB e gli ultimi soltanto nel 128GB - contengono il die V2 TLC K9ADGD8S0A che è confermato anche da te essere TLC ma anche dal tuo decoder di Samsung e dal decoder dello spreadsheet cinese data la terza "A". Tra l'altro da quel che leggo mi sembra che Blogger (https://chipworksrealchips.blogspot.com/2014/08/the-second-shoe-drops-now-we-have.html?m=1) confermi il fatto che venga usato in pMLC e la capacità venga ridotta a 86Gb:
Stranamente, il "DG" nel part number denota normalmente un die 128-Gb ma questa parte è in realtà ~86Gb visto che abbiamo dodici die flash nel nostro Solid-state drive 128-GB.

Loro non lo dicono chiaramente (penso non ci siano arrivati, sicuramente a quei tempi non si era mai sentito parlare di SSD/NAND flash pMLC) ma con un po' di logica ci si arriva.

Il package K9UMGB8S7A (usato nell'850 PRO da 2TB e trattato nella recensione di AnandTech) è senza ombra di dubbio V2 MLC e non esiste che è contenuto all'interno dei packgae "S5M" e "S1M", non esiste un package dentro un package... Quindi niente, rettifico: tutti i package dell'850 PRO che finiscono con "S5M" e "S1M" contengono all'interno il die "K9ADGD8S0A" (maledetta "A" finale :asd:) e che è TLC.

P.S.: l'ISSCC al quale Blogger si riferisce è quello da 24L (V1) ed è sbagliato, nel senso che hanno preso l'ISSCC sbagliato per quell'articolo, anche perché sotto qualche figura parlano di 32 wordline e chiaramente si capisce che hanno cannato a prendere ISSCC. Le V1, come detto da loro, hanno una dimensione del die di 133 mm² e una densità di bit di 0,96 Gb/mm² mentre le V2 TLC hanno una dimensione del die da 87,4 mm² (e anche questo lo dicono loro con "~85 sq.mm") e una densità di bit di 0,99 Gb/mm² in pMLC e 1,4 Gb/mm² in TLC (ma 128Gb).
Idem per il pacchetto K9PRGY8S5M: hai P che vuol dire MLC ODP (Octa die package)...

Sì Liupen ma son package diversi, non so se te ne sei accorto (io me ne sono accorto ora rileggendo il tuo commento). Io parlo del package K9HQGY8S5M trovato nell'850 PRO da 512GB di TweakTown e che TechInsights ha scoperchiato trovando il die V2 TLC K9ADGD8S0A, non parlo del package K9PRGY8S5M trovato da Tom's Hardware, AnandTech e TheSSDReview.

Se la produzione delle V2 TLC è iniziata ad ottobre 2014 com'è possibile che TweakTown abbia recensito un 850 PRO da 512GB il 1° settembre 2014 con all'interno package con die V2 TLC? ma soprattutto, come ha fatto TechInsights a scoprire il die V2 TLC K9ADGD8S0A contenuto all'interno del package K9HQGY8S5M il 17 settembre 2014 se l'inizio della produzione è iniziato ad ottobre?
Gombloddo. :asd:

Parlando seriamente, a 'sto punto mi sembrano due le cose: o quel die NAND flash è MLC e non TLC (e a 'sto punto il ragionamento fatto sull'articolo di Blogger non va bene così come entrambi i decoder presi in esame in questa discussione che segnano entrambi TLC con la terza "A") e anche tu ti sbagliavi nella tua analisi in formato PDF oppure la produzione e commercializzazione delle V2 TLC è iniziata prima di ottobre 2014 e Samsung ha mentito (anche se non vedo cosa potesse ottenere ai tempi Samsung nel mentire su una cosa del genere). Oppure, peggio ancora, l'850 PRO fino a 1TB contiene NAND flash V2 TLC anche per il package K9USGY8S7M (cosa che coincide con il decoder Samsung dello spreadsheet cinese) e poi quando hanno rilasciato il 2TB l'hanno fatto con le V2 MLC ma solo per quel taglio visto che usa package diversi (K9UMGB8S7A). Però questo mi farebbe pensare che Samsung ha avuto pronte fin da subito le V2 TLC (ancor prima di ottobre 2014 chiaramente) ma non le V2 MLC e per far uscire l'850 PRO gli abbia rifilato le V2 TLC facendole andare in pMLC. Poi una volta che hanno preparato perfettamente le V2 MLC le hanno fatte uscire nel 2TB.

Ti torna tutto questo ragionamento o sto sbagliando qualcosa? Per farla in breve:
L'850 PRO nei tagli da 256GB, 512GB e 1TB è stato lanciato con i package K9USGY8S7M e K9PRGY8S5M. Teoricamente questi package contengono die V2 MLC.
A settembre esce la recensione di TweakTown sull'850 PRO da 512GB. I package cambiano: da K9PRGY8S5M a K9HQGY8S5M e da K9USGY8S7M a K9PRGY8S7M. TechInsights trova che all'interno dei package K9HQGY8S5M ci sono i die K9ADGD8S0A che sono V2 TLC. Allora qui le cose cambiano e il 512GB per forza di cose è V2 pMLC, non V2 MLC, o perlomeno lo è metà visto che non sappiamo se anche i package K9PRGY8S7M contengono il die V2 TLC (secondo lo spreadsheet cinese sì però). Leggendo poi bene l'articolo di TechInsights sul die K9ADGD8S0A si scopre, però, che esso è contenuto anche nei package K9LPGY8S1M, package presenti nell'850 PRO da 128GB. L'850 PRO da 128GB, perciò, è pienamente pMLC visto che contiene sia i package K9LPGY8S1M e K9HQGY8S5M.

A 'sto punto mi pongo un quesito: visto che abbiamo appurato che il 128GB è full pMLC e che il 512GB è metà pMLC e metà MLC (faccio finta che i package K9PRGY8S7M siano V2 MLC visto che non ti fidi dello spreadsheet cinese), come la spieghiamo la presenza dei die V2 TLC a settembre 2014 (e anche prima) se Samsung ha iniziato la produzione ad ottobre?

Posta questa domanda, mi sale il dubbio che anche gli altri 850 PRO lanciati da subito (quindi luglio 2014) con i package K9USGY8S7M e K9PRGY8S5M siano pMLC con le V2 TLC e non V2 MLC. Lo spreadsheet cinese lo conferma ma sorvolo visto che appunto, come già detto, non ti fidi.
Questo è il teardown della prima serie di V-Nand 32L 86 Gbit fatto da TechInsights (SEM datati luglio-agosto 2014)
https://i.ibb.co/mrF9pg5V/Cattura10.png (https://ibb.co/rKfx9N2R)
come leggi si tratta del package K9HQGY8S5M

Ebbene, indovina un po QG (la densità di 341 Gbit) dove è stata catalogata?
Eh, pMLC!
Ma possibile!?!

Sì, è possibile. "L'unica 32L MLC 2-bit analizzata in ogni micron, il prototipo, la prima" che dici tu sarebbe il package K9PRGY8S5M, non il package K9HQGY8S5M. Il package K9HQGY8S5M contiene il die K9ADGD8S0A che come dici tu, io, il ragionamento fatto sull'articolo di Blogger e i due decoder di Samsung è TLC. Quindi no, questo non fa variare l'attendibilità dello spreadsheet e no, K9HQGY8S5M non è V2 MLC. Al massimo potremmo dire che sia il package K9PRGY8S5M V2 MLC ma solo perché dello spreadsheet cinese non ti fidi e perché non siamo sicuri di che die ci sia dentro, però l'articolo di Blogger è uscito ad agosto 2014 e lì c'è scritto del die V2 TLC K9ADGD8S0A trattato come un 86Gb con dimensione del die di 87,4 mm².
---------------------------------------------------------------------------------------------------
EDIT: leggo sia qui (http://tisensen.cn/index.php/archives/100/) che nello spreadsheet cinese (https://imgur.com/a/4ExjN8o) che sono uscite prime le NAND flash V2 TLC in die K9ADGD8S0A e K9ADGD8U0C delle V2 MLC (uscite nel 2015) in die K9GDGD8U0A. Questo vorrebbe dire che anche gli 850 PRO da 256GB e 1TB sono full pMLC, che l'850 PRO è stato lanciato con NAND flash V2 TLC in pMLC e spiegherebbe anche il motivo per il quale soltanto l'850 PRO da 2TB (uscito nel 2015) usa le V2 MLC uscite nel 2015.