SSD: thread generale e consigli per gli acquisti

[Nicodemo Timoteo Taddeo]

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)]

Originariamente inviato da nesema

Ciao a tutti



http://www.ssk.cn/Product_Center_details/21.html

usato poco



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]

Originariamente inviato da Black (Wooden Law)

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)]

Originariamente inviato da Nicodemo Timoteo Taddeo

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]

Originariamente inviato da Nicodemo Timoteo Taddeo

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à

[@Liupen]

Originariamente inviato da frafelix

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/l...ng-ssd-drives/
https://pcprompt.in/services/ssd-data-recovery/


Edit.

[frafelix]

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]

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]

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]

Originariamente inviato da frafelix

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/showp...ostcount=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.

Originariamente inviato da s12a

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.

Originariamente inviato da frafelix

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]

Originariamente inviato da @Liupen

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)]

InnoGrit 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]

Originariamente inviato da frafelix

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]

Che poi è quello che ha descritto Liupen con drat e dzat

[@Liupen]

Originariamente inviato da frafelix

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]

Decisamente! Grazie come sempre

[giovanni69]

@Black (Wooden Law)

..stupefacente?

[@Liupen]

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)]

Originariamente inviato da @Liupen

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.

Originariamente inviato da @Liupen

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 (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]

Originariamente inviato da Black (Wooden Law)

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 (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-o3...ew?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

Il “divenendo simili alle V-Nand 32L a 3 bit” lo capirai leggendo

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!