SSD: thread generale e consigli per gli acquisti

[frafelix]

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

Originariamente inviato da frafelix

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.

Originariamente inviato da frafelix

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]

Originariamente inviato da Black (Wooden Law)

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...

Originariamente inviato da Black (Wooden Law)

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

Originariamente inviato da frafelix

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... ?

Originariamente inviato da frafelix

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]

Originariamente inviato da Black (Wooden Law)

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

Originariamente inviato da Black (Wooden Law)

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]

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]

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]

Originariamente inviato da frafelix

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]

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]

Originariamente inviato da frafelix

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]

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]

Originariamente inviato da Black (Wooden Law)

Ammazza oh, sono usciti due articoli (di cui solo uno accademico) e adesso l'LCA delle NAND flash e degli SSD è diventato un trend.
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 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/lo...FIEDUI-PROFILE
Questo l'articolo
https://library.techinsights.com/hg-...26+Green+Power

Originariamente inviato da Black (Wooden Law)

@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 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.

Originariamente inviato da frafelix

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.

Originariamente inviato da Black (Wooden Law)

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!

Originariamente inviato da frafelix

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à.

Originariamente inviato da Black (Wooden Law)

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.

Originariamente inviato da frafelix

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

Originariamente inviato da @Liupen

Per TechInsights mi sono iscritto alla newsletter, basta l'account gmail https://auth.svc.techinsights.com/lo...FIEDUI-PROFILE
Questo l'articolo
https://library.techinsights.com/hg-...26+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.

Originariamente inviato da @Liupen

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]

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]

Originariamente inviato da Liupen;

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

Originariamente inviato da @Liupen

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.

Originariamente inviato da sbaffo

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:

Originariamente inviato da sbaffo

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]

Originariamente inviato da sbaffo

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.

Originariamente inviato da Black (Wooden Law)

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]

Ciao a tutti



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

usato poco



devo preoccuparmi ?

[frafelix]

Originariamente inviato da @Liupen

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...

Originariamente inviato da @Liupen

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

Originariamente inviato da @Liupen

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.

Originariamente inviato da @Liupen

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]

Spoiler:

Originariamente inviato da nesema Ciao a tutti http://www.ssk.cn/Product_Center_details/21.html usato poco 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.