Come spiegato da s12a immagina che tutti i supporti di storage, ma in particolare gli ssd, memorizzano utilizzando 2 livelli interconnessi: quando fai copia / incolla il sistema operativo dice che il file X deve essere scritto sul supporto e lo divide nei più piccoli frammenti memorizzabili X1, X2, X3...ecc; fatto questo manda in cache (di Windows) e l'ssd che riceve il comando che fa? Il controller con il TRIM sa le celle vuote scrivibili e memorizza i frammenti, se può sequenzialmente, se no in ordine sparso. Il controller chiama i frammenti Y1, Y2, Y3..ecc e sono entità fisiche (porzioni di blocco).
Qualora tu voglia leggere il file, il Sistema operativo si avvale di una tabella di conversione (continuamente aggiornata) del file system che lega univocamente il file come lo conosci tu, agli spezzoni di file come li vede il sistema operativo, agli spezzoni di file realmente memorizzati come li vede l'SSD.
Due piani differenti e autonomi; infatti l'SSD sposta a suo piacere i frammenti Y1, Y2, Y3..ecc (per organizzare secondo algoritmi di livellamento e Garbage Collection) ad esempio possono con successivi passaggi finire in Y6, Z4, D25, ecc ma sono comunque associati sempre a X1, X2, X3...ecc come "indirizzo" del Sistema operativo.

Il software che legge i dati raw,
legge A1,A2, A3.....ecc il dato memorizzato indipendentemente dall'appartenenza al file

Il software che legge i file
legge il nostro file creato una certa data ma dietro in realtà c'è la ricostruzione appunto dei frammenti Y6, Z4, D25...ecc prendendoli dalle varie parti del SSD

s12a ha dimostrato empiricamente che la frammentazione anche sugli ssd, ha un certo impatto nella lettura, quindi per quanto quel piccolo software abbia dimostrato a Samsung che i file memorizzati da più tempo tendenzialmente tendevano a essere letti meno velocemente (perchè tendevano a corrompersi), non è un software perfetto, poichè più vecchi sono i dati memorizzati sull'ssd più sono frammentati più vengono letti lentamente sia per il decadimento della cella ma anche per la frammentazione stessa.

"Deframmentare un SSD è dannoso" è una frase da vecchie istruzioni sul funzionamento degli ssd con: disattiva l'indicizzazione, disattiva prefetch, ecc
Compattare ogni tanto il DB sull'SSD fà bene, ma scrive le celle.
Ora però che l'affidabilità degli ssd è comprovata...nessun problema a farlo.

Eh si!
Tu figurati Max erano gli anni che l'ssd, pur costoso, diventata un must per gli utenti "normali" e quelli Samsung erano proprio il top. Insomma una fi...ta averli quando in pochi sapevano cosa fosse un ssd!
Ogni giorno 10 bench e 100 commenti... e si doveva combattere coi i detrattori degli ssd che dicevano che "morivano presto" :p
Alla notizia del bug dei Samsung, ci fù un ansia generale, perchè Samsung ci mise un bel po di settimane a rispondere adeguatamente.
Di peggio, ricordo, ci fù solo il bug del Crucial M4 e il firmware assassino di Samsung.. ma sicuro che come risonanza vinse il bug dell'840 :D

ti ringrazio per la chiarissima spiegazione ma non era quella che cercavo :p
Ahem sono nel settore dagli anni 80 e ci mancherebbe che non sapessi come funziona lo storage :D
Non capivo il punto del discorso di s12a (che poi si è spiegato benissimo, e l'hai ribadito altrettanto chiaramente tu qui sopra ;) ).
All'epoca del bug del Crucial e del firmware di Samsung ero qui e postavo, e da bravo appassionato cronico compravo i primi SSD tra mille dubbi sulla loro durata nel tempo.

Però resto dell'idea che deframmentare un SSD, a meno che non ci siano problemi intrinsechi come quelli a cui fa riferimento s12a per il modello 840, non sia saggio e senza dubbio non vada fatto così in modo "preventivo".

Già che ci siamo: l'ottimizzazione SSD di windows che cosa fa?

sostanzialmente un ciclo di trim manuale ;)

ciao ciao

Scusami Max, sono iscritto da poco e non mi ero accorto della tua iscrizione 2003 da veterano... :D inizio a scrivere e non mi fermo

Personalmente non l'ho fatto in modo preventivo ma ho lasciato prima fare a SSDkeeper e poi ho forzato una ottimizzazione che ha ripristinato gran parte delle performance perdute. Ho postato i risultati ed il contesto in qualche pagina addietro.

non ti devi mica scusare.
Al di la dell'appartenenza alla community da anni, il bello di questi posti è che puoi sempre trarre insegnamento dall'esperienza altrui, per competenza o anche solo perché magari uno ci si è già dovuto scontrare di persona con certe problematiche :boh:

Mi sono piaciuti molto i test fatti da a12s ad esempio e mi era sfuggita la questione 840 all'epoca (non ho mai avuto un SSD Samsung se non dentro un Mac, perché per motivi diversi nei PC ho sempre montato altro).

Approfondimento molto interessante quello che avete appena fatto ;)

Devo acquistare un ssd da 2tb che per questi primi mesi utilizzerò per W10 ma che poi, per i prossimi anni, sfrutterò solo come disco storage per i dati (sempre acceso interno al pc).

Inizialmente volevo prendere un 860 evo, poi però ho visto che risparmierei 85 euro prendendo un 860 QVO. Non so se la differenza siano solo i TBW, di certo i dati una volta che li sposterò non andrò più a toccarli, ne aggiungerò e basta.

Per l'utilizzo che ne farei sono 85 euro che posso risparmiare?

per usarlo come ssd da OS no, meglio non risparmiare

per usarlo come ssd storage invece sì


con tutto quanto concerne le celle 4-level rispetto a quelle 3-leve di cui si era già parlato tempo fa in altro thread a cui partecipasti (ma forse ricordo male :stordita: )


male comunque pensare di non toccare più i dati, proprio visto quanto esposto in queste ultime pagine e quanto scritto nell'altro thread sull'inconsistenza dei dati per ssd non alimentati e/o usati come data storage ;)

poi, my 2 cents eh

ciao ciao

Ciao, per quanto riguarda le celle mi devi aver confuso con un'altro utente :)

Non capisco perchè debba riguardare me visto che io l'ssd lo alimento sempre, e non essendo un samsung 840 o un crucial mx500 oggetto di discussione di queste ultime pagine, non rientro neanche in quella casistica.

Per il resto parlando di non toccare i dati intendevo che non cancello e riscrivo grosse quantità in relazione al TBW, poi i miei backup li faccio a prescindere.

Nel thread a cui ri riferisci poi si è concluso il discorso che non ci sono particolari controindicazioni nell'usare come storage un ssd sempre alimentato.

Non ci sono controindicazioni, i costruttori degli SSD hanno già acquisito l'esperienza necessaria per predisporre i firmware a poter conservare in maniera ragionevole i file per tempi lunghi. Ma anche ci fossero, le regole per il backup ragionevole ti pongono al riparo e fanno in modo che te ne puoi cagafottere della persistenza su SSD, refresh e "menate" del genere.

La regola principale è quella del 3-2-1:

I tuoi file dovrebbero essere conservati in tre dispositivi di archiviazione diversi, uno può essere nel tuo computer stesso. E quindi SSD senza problemi.

Dovresti adoperare almeno due tipi di dispositivi diversi di archiviazione. Cioè non solo SSD, ma sia SSD che Hard Disk esterno tradizionale, NAS, DVD, nastro, tavolette di cera incise col pennino, lastre di pietra incise con lo scalpellino ecc. ecc. :)

Almeno uno di questi dispositivi dovrebbe stare fuori dal locale in cui stanno gli altri, lontano. Un altro edificio, possibilmente a qualche chilometro, meglio centinaia o migliaia di chilometri. E qui entra in gioco il cloud.


Seguendo la regola del 3-2-1 non ci pensi più alla persistenza dei dati negli SSD, ai rischi delle rotture meccaniche degli hard disk, al rischio di furto dei dispositivi o a quello di incendio, terremoto o inondazione della tua casa o ufficio. Hai altre due copie dei tuoi file, una lontano.

Cosa ne pensate?

https://www.reddit.com/r/Amd/comment...0_compared_to/

:mano: :ave:
Ed a quel punto non pensi nemmeno ai TBW, al tipo di celle TLC vs MLC, ecc. ovvero 1/4 dei post contenuti in questo thread. :D

Ok grazie, per ora mi sono sempre fermato alla 2. Alla 3 arriverò.

Magari sto per scrivere una banalità ma vorrei togliermi il dubbio, se un documento o una foto che non apro mai dovesse corrompersi nel tempo a causa delle celle (o altri motivi) ed io non me ne accorgessi, nel momento in cui andrei a fare un backup tale dato potrebbe non venir letto (restituendo errore in lettura) o magari trasferito con degli errori? perchè nel secondo caso potrei si fare backup stando tranquillo ma anche le mie copie si porterebbero dietro gli errori dell'ssd interno. Sbaglio?

I software di backup spesso hanno opzioni del tipo "fermati se c'è un errore di lettura" o comunque un log a fine operazione che segnala quel tipo di problema. Se poi temi comunque che si avveri quel problema sul sorgente, c'è sempre il refresh di cui si è discusso diverse volte.

Diciamo che ho iniziato a temerlo dopo aver letto thread come questo :), altrimenti non mi sarei mai posto il problema.

Il software che utilizzo propaga solo le modifiche e aggiunge/toglie i file sul disco di backup rispetto alla sorgente. Quindi dovrei essere abbastanza a posto. Poi non so altri software come si comportino e che tipo di check effettuino.

Sì, prendi pure il qvo. Tra l'altro sull'amazzone è scontato ora. ;)

Non si tratta degli algoritmi di backup differenziale o incrementale o di altra natura ma di integrità della leggibilità del file.

see, spiegaglielo te :D


@ShineOn

banalmente sì, con gli ssd più facile la seconda eventualità

qvo = celle QLC, ti lascio approfondire :mano:

nel mentre hai poi comprato il disco nvme da usare per giocare a iracing?

ciao ciao