SSD: thread generale e consigli per gli acquisti

[isomerasi]

Originariamente inviato da megthebest

non solo, sui Sata investono ormai 0, nessuna novità per controller o nand, tendono a svuotare i magazzini di roba non più competitiva da ficcarci su..

ma quando si svuotano i magazzini però la roba la si sconta, mica la si fa aumentare di prezzo...

Originariamente inviato da HSH

Diamine mi toccherà riutilizzare i vecchi samsung EVo850 da 256gb

almeno quelli sono buoni...ne ho uno da 500GB che ha 8 anni e mezzo ed è perfetto...peccato però che lo pagai 186 euro...

Originariamente inviato da Yrbaf

Beh principalmente per il costo al GB (o se vuoi al TB) più sfavorevole e perché non sono fatti per conservare i dati a lungo da spenti.

Il tempo preciso dopo il quale si perdono dei dati non lo sa quasi nessuno, ma a seconda della temperatura di conservazione può essere anche inferiore all'anno e di solito le celle sono garantite solo per un anno a max 30 gradi.
Il che non vuol dire che subito dopo ci saranno perdite ma solo che 12 mesi a 30 gradi sono garantiti come non in grado di fare danni.
Mentre per gli HDD la retention è un tempo molto più lungo (non ricordo il dato potrei dire da 8/10 anni a salire)

Poi per carità se SSD lo lasci acceso e lo usi ogni tanto allora il controller dovrebbe periodicamente rinfrescare (alias leggere e copiare da altre parti) i dati che segnalino l'insorgere di qualche problema, facendo ripartire il contatore (non assoluto) di vita dati per quei dati (ma non credo per tutto il disco).
Mentre un HDD non fa nulla di ciò anche se ogni tanto continui a leggerlo e sei tu che periodicamente devi rinfrescare i dati (se ci tieni a decenni di conservazione) con tool appositi (o semplicemente copiando da un HDD ad un altro).

Una volta si usavano i supporti magneto-ottici e per quelli mi pare che si garantissero 30 anni di conservazione dati.
Anche i nastri di backup dovrebbero avere elevate data retention

beh, se si utilizza un ssd come backup, lo si fà per sbrigarsi...quindi si presume che i backup si facciano più o meno frequentemente...male che vada una volta ogni 2 mesi...quindi il problema non sussiste...e ovviamente ogni tanto si riversa il tutto su un hd meccanico...

[piwi]

Originariamente inviato da Black (Wooden Law)

Sì, sicuramente il Crucial BX500 è migliore

Va bene ... grazie. Proporrò questi. Tra le marche meno note / "cinesumi", di SATA, si salva qualcosa ?

[isomerasi]

Originariamente inviato da piwi

Va bene ... grazie. Proporrò questi. Tra le marche meno note / "cinesumi", di SATA, si salva qualcosa ?

io consiglierei solo roba buona, ma se non voglio spendere...meglio il bx che i cinesi...

[Yrbaf]

Originariamente inviato da giovanni69

Se non sbaglio c'è un utente del thread che ha programmato di rinfrescare tra qualche anno un suo SSD per vedere se sarà ancora integro o...meno. E nel frattempo lo tiene in un armadio.

Beh volendo io ho un 160GB (credo modello 2013-14) in uno scatolone che credo sia spento da 6 anni se non di più (tipo spento dal 2015-16).
Ed un altro 120GB (questo più del 2016-18) montato in un sistema che credo di aver acceso negli ultimi 3 o 4 anni forse 10 volte e sarà già 6 mesi che è spento.

Volendo (tanto prima o poi pensavo di recuperarlo) potrei riaccenderlo (il primo) e vedere se ci sono ancora su dei dati (non ricordo se l'ho formattato, ma di certo il suo contenuto è stato copiato) e se ci sono se hanno delle perdite (anche se non saprei che sw usare per scoprire file corrotti causa data retention andata) anche se essendo ancora MLC dovrebbe essere più longevo sulla retention

Comunque altri SSD (dei 860EVO da 250GB) oltre ai due già citati in passato li ho lasciati spenti a lungo (anche fino a 2 anni nel caso peggiore) senza preoccuparmi (magari sbagliando) della possibile perdita di dati.
E non ho mai notato (ma neanche ho fatto test approfonditi) problemi alla riaccensione.

Finora l'unico SSD che mi ha dato un problema (ino) è stato un 850EVO da 1TB che pochi mesi fa dopo forse 5-6 anni di uso ha generato un bad block poi riallocato con perdita di un file sul file system (file poco vitale anzi pure cancellabile ormai e pure per fortuna, non li faccio quasi mai, backuppato).
Però era anche con TBW quasi al 100% (anche se marcato ancora Buono da Magician).
Mi sono accorto del problema perché avevo lanciato una lettura di tutti file (per fare hashing degli stessi) ed arrivato a quello non riusciva più a leggerlo e lanciando una scansione superficiale un blocco compariva come bad (sparito dopo la riformattazione, ma comparsi settori riallocati nei dati Smart).

[giovanni69]

Originariamente inviato da Yrbaf

Mi sono accorto del problema perché avevo lanciato una lettura di tutti file (per fare hashing degli stessi) ed arrivato a quello non riusciva più a leggerlo e lanciando una scansione superficiale un blocco compariva come bad (sparito dopo la riformattazione, ma comparsi settori riallocati nei dati Smart).

Potresti per favore spiegare nel dettaglio cosa consiste questa procedura di verifica? Personalmente ho presente solo cosa sono gli hash di un ISO.

[frafelix]

Se non mi ricordo male la data retention di 1 anno era con l'ssd a fine vita, quindi con tutte le celle scritte il loro massimo numero di volte. Negli altri casi non dovrebbe essere un problema... Comunque non è una caso che ogni produttore gestisce come vuole, è uno standard JEDEC

[gabmac2]

è più che altro una curiosità
un dato può essere sovrascritto in vari modi (per wipe)
sovrascrivere un dato con 0, con 1, con valori casuali di 0 o 1 o con DoD 5220.22-M, cosa cambia a livello pratico?
grazie in anticipo

[makka]

Non fa testo, ma per curiosità ho appena acceso un vecchio Hp6735s dove ho messo il mio primo ssd, un Crucial M4 da 128Gb.
Spento da dicembre 2022, acceso oggi e funziona perfettamente, sta aggiornando Windows 10 ... con una lista di cose in download paurosa !!

E' comparso addirittura il banner "Preparati per Windows 11"...

[giovanni69]

@makka: In effetti non fa testo... non è esattamente un test esaustivo per verificare il data retention. Sopra Yrbaf parlava di hashing dei files.

Ma fa sempre piacere ed è confortante vedere che un SSD almeno.... si accenda

Originariamente inviato da frafelix

Se non mi ricordo male la data retention di 1 anno era con l'ssd a fine vita, quindi con tutte le celle scritte il loro massimo numero di volte. Negli altri casi non dovrebbe essere un problema... Comunque non è una caso che ogni produttore gestisce come vuole, è uno standard JEDEC

Qualche settimana fa, @Liupen si era espresso qui sul data retention.

[frafelix]

Originariamente inviato da gabmac2

è più che altro una curiosità
un dato può essere sovrascritto in vari modi (per wipe)
sovrascrivere un dato con 0, con 1, con valori casuali di 0 o 1 o con DoD 5220.22-M, cosa cambia a livello pratico?
grazie in anticipo

Stai parlando di una cosa valida per gli hd meccanici; in questi ci sono diversi tipi di formattazione per essere abbastanza certi che nessuna società con strumenti avanzati possa recuperare i dati. Ci sono formattazioni con soli 0, con soli 1 e con dati casuali, il tutto per N volte l'intera dimensione del disco.
Con l'ssd non hanno senso e andrebbero a diminuire la vita delle celle inutilmente (scrivendo tutte le celle per N volte). Su queste c'è il wipe o il secure erase che viene fatto a livello di firmware ed agisce sull'elettronica per azzerare i dati

[gabmac2]

Originariamente inviato da frafelix

Stai parlando di una cosa valida per gli hd meccanici; in questi ci sono diversi tipi di formattazione per essere abbastanza certi che nessuna società con strumenti avanzati possa recuperare i dati. Ci sono formattazioni con soli 0, con soli 1 e con dati casuali, il tutto per N volte l'intera dimensione del disco.
Con l'ssd non hanno senso e andrebbero a diminuire la vita delle celle inutilmente (scrivendo tutte le celle per N volte). Su queste c'è il wipe o il secure erase che viene fatto a livello di firmware ed agisce sull'elettronica per azzerare i dati

ad esempio Kingstone fornisce una procedura per sata3, ma non nvme
genericamente una semplice scrittura di zeri è sufficiente per eliminare definitivamente un file?

[@Liupen]

Originariamente inviato da giovanni69

Se non sbaglio c'è un utente del thread che ha programmato di rinfrescare tra qualche anno un suo SSD per vedere se sarà ancora integro o...meno. E nel frattempo lo tiene in un armadio.

Molto interessante... roba da s12a è lui?!

Originariamente inviato da frafelix

Se non mi ricordo male la data retention di 1 anno era con l'ssd a fine vita, quindi con tutte le celle scritte il loro massimo numero di volte. Negli altri casi non dovrebbe essere un problema... Comunque non è una caso che ogni produttore gestisce come vuole, è uno standard JEDEC

Tanto complicata, tanto poi lontana dalla realtà:
Jedec impone che i dati si scrivano ad una temperatura X e che l'ssd venga conservato ad una temperatura Y; e ancora non dice che i dati devono poi esserci tutti, ma che ne rimanga con un tasso di errore sotto una soglia Z (UBER)

Originariamente inviato da gabmac2

è più che altro una curiosità
un dato può essere sovrascritto in vari modi (per wipe)
sovrascrivere un dato con 0, con 1, con valori casuali di 0 o 1 o con DoD 5220.22-M, cosa cambia a livello pratico?
grazie in anticipo

In un ssd?
I primi 2 metodi sono una singola cancellazione (pari ad 1 ciclo p/e), ma se utilizzi metodi di sovrascrittura multipla ti ritroverai cancellazioni aggressive delle celle e altrettanto consumo di cicli p/e.

Con: Ciclo p/e = quantità di GB del ssd = 1% in meno di vita in Crystaldiskinfo*

Suppongo che con cancellazioni multiple, gli algoritmi di livellamento e garbage collection (che ovviamente non sanno cosa vuoi fare), creino una coda di write amplification che si sommerà alle cancellazioni, quindi magari (ipotizzo) un DoD 5220.22-M ne toglie 8% di vita e non solo 7.

Insomma, ogni scrittura per l'ssd è un "predisporsi", che equivale a cancellare blocchi azzerando le celle di cui sono costituiti e questo sia che tu scrivi degli 0 sia che scrivi degli 1, anche se la cancellazione per accogliere il nuovo dato, coincide poi con il valore 1

vedi https://www.kioxia.com/content/dam/k...img_004_en.png

Originariamente inviato da gabmac2

ad esempio Kingstone fornisce una procedura per sata3, ma non nvme
genericamente una semplice scrittura di zeri è sufficiente per eliminare definitivamente un file?

Ma anche per un HDD una riscrittura era più che sufficiente.
Con i software "normali" si riescono a recuperare dati solo se non si vanno a riscrivere quelli cancellati che in realtà sono ancora li e ad andare perso era la mappatura delle partizioni e l'indice dei frammenti dei files.

Per un ssd vale questo stesso ragionamento (una scrittura è sufficiente per cancellare) ed in più - ai fini del recupero dati - il tipo di dispositivo con trim attivo tende ad anticipare la cancellazione dei blocchi per far spazio alle scritture, mescolando i frammenti dei files. Diventa molto difficile.

EDIT: * NB. se l'ssd è scritto completamente ma c'è spazio che windows, linux, ecc considera libero, è probabile che ci siano già blocchi che l'ssd considera cancellati e che non cancellerà nuovamente; quindi magari non scende subito di 1, la % di vita dell'ssd.

[gabmac2]

Originariamente inviato da @Liupen

Molto interessante... roba da s12a è lui?!





Tanto complicata, tanto poi lontana dalla realtà:
Jedec impone che i dati si scrivano ad una temperatura X e che l'ssd venga conservato ad una temperatura Y; e ancora non dice che i dati devono poi esserci tutti, ma che ne rimanga con un tasso di errore sotto una soglia Z (UBER)





In un ssd?
I primi 2 metodi sono una singola cancellazione (pari ad 1 ciclo p/e), ma se utilizzi metodi di sovrascrittura multipla ti ritroverai cancellazioni aggressive delle celle e altrettanto consumo di cicli p/e.

Con: Ciclo p/e = quantità di GB del ssd = 1% in meno di vita in Crystaldiskinfo*

Suppongo che con cancellazioni multiple, gli algoritmi di livellamento e garbage collection (che ovviamente non sanno cosa vuoi fare), creino una coda di write amplification che si sommerà alle cancellazioni, quindi magari (ipotizzo) un DoD 5220.22-M ne toglie 8% di vita e non solo 7.

Insomma, ogni scrittura per l'ssd è un "predisporsi", che equivale a cancellare blocchi azzerando le celle di cui sono costituiti e questo sia che tu scrivi degli 0 sia che scrivi degli 1, anche se la cancellazione per accogliere il nuovo dato, coincide poi con il valore 1

vedi https://www.kioxia.com/content/dam/k...img_004_en.png



Ma anche per un HDD una riscrittura era più che sufficiente.
Con i software "normali" si riescono a recuperare dati solo se non si vanno a riscrivere quelli cancellati che in realtà sono ancora li e ad andare perso era la mappatura delle partizioni e l'indice dei frammenti dei files.

Per un ssd vale questo stesso ragionamento (una scrittura è sufficiente per cancellare) ed in più - ai fini del recupero dati - il tipo di dispositivo con trim attivo tende ad anticipare la cancellazione dei blocchi per far spazio alle scritture, mescolando i frammenti dei files. Diventa molto difficile.

EDIT: * NB. se l'ssd è scritto completamente ma c'è spazio che windows, linux, ecc considera libero, è probabile che ci siano già blocchi che l'ssd considera cancellati e che non cancellerà nuovamente; quindi magari non scende subito di 1, la % di vita dell'ssd.

il trim non è attivo di default ovunque ormai?
in caso contrario quindi una scrittura di zeri o uni è sufficiente, al limite scrittura random ?

[Yrbaf]

Originariamente inviato da giovanni69

Potresti per favore spiegare nel dettaglio cosa consiste questa procedura di verifica? Personalmente ho presente solo cosa sono gli hash di un ISO.

E' la stessa identica cosa degli ISO, solo fatto su tutti i files esistenti ed accessibili e magari cambiando il tipo di Hash usato.

Ci sono vari tool che lo fanno e serve principalmente per :

• Scoprire duplicati in giro, anche quando questi hanno nomi diversi e/o date di ultima modifica diverse
• Scoprire file alterati (anche quando non dovrebbero esserlo) dopo la firma
  E quindi scoprire file corrotti per errori sul filesystem o anche solo file in cui è stato aggiunto qualcosa di nascosto (virus ??)

Un tool per Windows che fa queste cose è HashMyFiles di NirSoft
Peccato non abbia mai messo Hash veloci tra le opzioni

Poi lo fa anche jDupes (da riga di comando), il quale ha lo scopo di ricercare il più velocemente possibile duplicati e poi elencarli, cancellarli (tutti tranne una copia), sostituirli con HardLink (rimangono tutti i duplicati ma lo spazio su disco diventa di una singola copia)

E altri tool sia grafici che non.

Nel mio caso credo che lo stessi facendo con uno script da me fatto in Python3 che elenca tutti i files in un percorso (e sotto percorsi) e li butta in un DB per poi farci (a mano) query di analisi e costruzione script di modifica filesystem.
Tra le opzioni permette anche (con tutto il tempo che ci vuole a leggere ogni singolo file e calcolarne l'hash) di calcolare l'Hash iniziale (idea rubata a jDupes ed altri deduplicatori) e completo del file (e riportarlo in update sul DB).
In questo caso uso xxHash 128 per massimizzare le prestazioni

Originariamente inviato da giovanni69

@makka: In effetti non fa testo... non è esattamente un test esaustivo per verificare il data retention. Sopra Yrbaf parlava di hashing dei files.

Ah certo che se fai l'hashing di tutti i file, prima di spegnerlo e metterlo da parte, ti accorgi di certo se qualcosa è andato male sulla data retention.

Già il fatto che per fare di nuovo l'hashing di tutto (per fare un confronto firme) devi rileggere tutto di nuovo, ti dovrebbe fare scoprire celle non più leggibili.
Ma anche nel caso il disco non segnalasse gli errori di lettura, ma semplicemente fornisse dati casuali da celle deteriorare, di certo la firma Hash divergerebbe e scopriresti i file coinvolti nella perdita di dati (per sapere i singoli blocchi devi fare un confronto con una copia buona altrimenti non c'è modo, se non è il disco stesso a segnartelo).

[@Liupen]

Originariamente inviato da gabmac2

il trim non è attivo di default ovunque ormai?
in caso contrario quindi una scrittura di zeri o uni è sufficiente, al limite scrittura random ?

Assolutamente, se devi darlo via per me è ampiamente sufficiente una cancellazione per riscrittura.
Se l'ssd è di quelli più "noti", il produttore ha poi un tool apposta per la cancellazione, che ne ripristina anche la velocità iniziale.
Ma una formattata normale in caso di reinstallazione - visto il TRIM - è veloce e comunque efficace.

Il TRIM è ovunque supportato da os "moderni" e passa, ad esempio, anche via usb (oltre sata ed nvme/u2).

[giovanni69]

Originariamente inviato da @Liupen

Molto interessante... roba da s12a è lui?!

No, non ho memoria che fosse lui.

Yrbaf, mi sono perso nel passaggio da:

Originariamente inviato da Yrbaf

Mi sono accorto del problema perché avevo lanciato una lettura di tutti file (per fare hashing degli stessi) ed arrivato a quello non riusciva più a leggerlo e lanciando una scansione superficiale un blocco compariva come bad (sparito dopo la riformattazione, ma comparsi settori riallocati nei dati Smart).

a:

Originariamente inviato da Yrbaf

E' la stessa identica cosa degli ISO, solo fatto su tutti i files esistenti ed accessibili
Ah certo che se fai l'hashing di tutti i file, prima di spegnerlo e metterlo da parte, ti accorgi di certo se qualcosa è andato male sulla data retention.

Già il fatto che per fare di nuovo l'hashing di tutto (per fare un confronto firme) devi rileggere tutto di nuovo, ti dovrebbe fare scoprire celle non più leggibili.
Ma anche nel caso il disco non segnalasse gli errori di lettura, ma semplicemente fornisse dati casuali da celle deteriorare, di certo la firma Hash divergerebbe e scopriresti i file coinvolti nella perdita di dati (per sapere i singoli blocchi devi fare un confronto con una copia buona altrimenti non c'è modo, se non è il disco stesso a segnartelo).

In termini pratici - nella prima citazione - vuoi dire che non avevi ancora fatto l'hashing ma con la sola lettura del file, si è rivelata la mancata integrità fisica del file.
Allora per questa verifica basterebbe anche solo una scansione antivirus? Ricordo che Eset scanner ancora anni fa individuava i files 'illeggibili'.


Quanto alla verifica dell'hash per un controllo di integrità che descrivi di par di capire che sarebbe impraticabile fare un confronto tra calcolo dell'hash di centinaia di migliaia di files, rispetto ad un indice hash dei medesimi effettuati in precedenza. Non è certo come indidividuare duplicati o comparazione side-by-side tra SSD/HD con Beyond Compare e simili...

[Yrbaf]

Originariamente inviato da giovanni69

In termini pratici - nella prima citazione - vuoi dire che non avevi ancora fatto l'hashing ma con la sola lettura del file, si è rivelata la mancata integrità fisica del file.

No ho detto che stavo facendo (credo, poi se è successo in altre situazioni boh) una scansione di tutti i dischi (compresi quelli usb, quelli sul Nas, quelli su altre macchine, ...ecc) per costruirmi un elenco unico di tutti i file e relativo Hash.

Scopo trovare duplicati (anche in dischi separati) nonché avere un elenco unico in cui cercare files (roba tipo "mi chissà dove cavolo sta il file che contiene la parola "Esteso" nel suo nome", ricerca che puoi fare in pochi secondi anche su milioni di record se ha un lista unica e magari in un DB).

Per fare tutti gli Hash è stato necessario leggere interamente tutti i files.
Ed arrivato su alcuni file in una certa cartella su una certa partizione su un certo disco ha dato read error (mi pare) facendomi notare una situazione che non doveva sussistere in mondo senza problemi.

Allora per questa verifica basterebbe anche solo una scansione antivirus? Ricordo che Eset scanner ancora anni fa individuava i files 'illeggibili'.

Forse non conosco il prodotto e non posso fare commenti.
Ma lo scopo iniziale (per me) non era cercare file illeggibili ma solo firmare tutto quello che esiste nei miei file system.

Quanto alla verifica dell'hash per un controllo di integrità che descrivi di par di capire che sarebbe impraticabile fare un confronto tra calcolo dell'hash di centinaia di migliaia di files, rispetto ad un indice hash dei medesimi effettuati in precedenza. Non è certo come indidividuare duplicati o comparazione side-by-side tra SSD/HD con Beyond Compare e simili...

No perché impraticabile ?

Certo se lo fai a mano tra due liste testuali ti do ragione, ma fatto via DB sarebbe una banale query in cui gli chiedi di trovare quali file a parità di path e nome (e magari dimensione) hanno due hash diversi tra due fotografie diverse dello stato dischi.
Ti trova in poco tempo (dipende da quanti record hai e da come è fatto il DB) quali file hanno cambiato firma tra una foto ed un'altra.

Cioè se hai una foto (elenco con tutti gli Hash) a Giugno 2023 e la confronti con la foto fatta a Gennaio 2024, tutti i file in comune tra le foto, che non sono stati volutamente modificati DEVONO avere lo stesso hash.
Dove non è così o qualcosa ha modificato a tua insaputa il file, o il file si è corrotto sul filesystem / supporto di memorizzazione.

Poi ho detto (nella parte che tu hai evidenziato) che l'hash ti dice solo che il file è cambiato ma non ti dice dove è cambiato.
Per scoprire quello devi per forza avere una copia vecchia del file e confrontarla con la copia che è risultata cambiata.
Se non hai entrambe le copie ma solo l'ultima versione non c'è modo di sapere dove sia cambiato e neanche quanta parte sia cambiata (1 blocco da 4k, 1MB di roba, il 90% del file è ora diverso, c'è tutto il file vecchio più aggiunte in coda, ...ecc)

[gabmac2]

Originariamente inviato da @Liupen

Assolutamente, se devi darlo via per me è ampiamente sufficiente una cancellazione per riscrittura.
Se l'ssd è di quelli più "noti", il produttore ha poi un tool apposta per la cancellazione, che ne ripristina anche la velocità iniziale.
Ma una formattata normale in caso di reinstallazione - visto il TRIM - è veloce e comunque efficace.

Il TRIM è ovunque supportato da os "moderni" e passa, ad esempio, anche via usb (oltre sata ed nvme/u2).

ok
ad esempio una scrittura random con DiskGenius può bastare quindi?

[@Liupen]

Originariamente inviato da gabmac2

ok
ad esempio una scrittura random con DiskGenius può bastare quindi?

Non conosco il software nello specifico.
Se è questa la descrizione che fà per quanto concerne la cancellazione dei dati:
https://www.diskgenius.com/how-to/ho...hard-drive.php
sembra uno scritto molto vecchio (vecchio nella sostanza) incentrato sugli HDD che non sugli SSD.

Spero riscriva con dati casuali un ssd, perchè parlare di settori per un ssd è parlare di qualcosa di fittizio. Un ssd simula di avere settori a livello logico ma è un array di blocchi fisici indifferenziati.
Inoltre, per lo stesso motivo, non si applica ciò che è scritto per la cancellazione di singole cartelle o file se si tratta di un ssd.

Cerco di fare un esempio a livello teorico.
se in un HDD hai memorizzato dei file così:
A-B-C-0-0-D
e quindi chiedi al software di cancellare 1 file, mettiamo B, lui cerca B (in realtà i frammenti che compongono B, i riferimenti in mappatura logico/fisica) e li elimina, credo, sovrascrivendo con dati fittizi (se no è fuffa).
Ottieni quindi
A-E-C-0-0-D
con E che è il dato fittizio.

se hai questo e altri software (creati per HDD) e lo utilizzi su un SSD, quindi stessa sequenza e volendo cancellare B, avrai:
A-0-C-0-0-D --> A-0-C-E-0-D
cioè con l'intenzione di scrivere sul blocco logico dove stava B, il software non fà altro che dire al controller che in B non c'è più un file valido, e poi la scrittura del nuovo file avviene in una posizione fisica diversa (che ha preso il posto della posizione logica precedente). Ottieni una sequenza per gli algoritmi di TRIM e livellamento in cui: la sovrascrittura E viene messa in un blocco nuovo.
Gli effetti di una sovrascrittura di un singolo file su ssd hanno provocato solo cancellazioni e riscritture laddove bastava semplicemente effettuare una cancellazione del file "normale", cancellazione che prevede l'azzeramento di buona parte delle celle di un blocco e l'impossibilità di recupero per software DR.

Spero di essermi un po spiegato..


Quindi la risposta, se il software fà quello che dice e non è fuffa: SI, basta, anzi.
Il metodo ad 1 passaggio zero fill che penso corrisponda all'opzione 00 o FF, crea uno spostamento generale dei blocchi a livello logico.

[Grezzo]

i prezzi dei dischi nvme continuano ad aumentare, ormai sono fuori controllo

Mi sa che posticiperò l'acquisto del disco perchè spendere il 20-40% in più della scorsa estate non lo accetto