SSD: thread generale e consigli per gli acquisti

[@Liupen]

Originariamente inviato da giovanni69

A proposito di questo, un dubbio mi è sempre rimasto: si vede il LED di funzionamento del dispositivo SSD quando ciò avviene o il fatto che sia trasparente all'utente non si riscontra nemmeno da lì?

La spia indica attività sull'interfaccia (vado solo di logica).

Ne ha una la mainboard, ne ha una il box storage esterno.
Quindi a meno che non ce l'abbia l'ssd stesso, direi che il led si illumina per la sola attività dell'host e non del GC/WL

[@Liupen]

Originariamente inviato da Tennic

Non ho capito

Quando avviene il WL, lo spostamento è a livello di controller, il file system non viene interessato, non è una copia comandata dal sistema operativo, quindi la data di ultima modifica del file non cambia di certo... Magari però non ho capito bene che intendi

Aspetta che c'è una contraddizione nel tuo pensiero.
Se lo spostamento avviene a livello di controller (ed è così), il controller che agisce per gli algoritmi di WL ignora cosa ci sia sulle celle, quindi anche i file che costituiscono l'OS (la parte più vecchia di una installazione), dovrebbero spostarsi.

Però ho sempre avuto l'impressione che ci siano molti dati statici e che lo spostamento seguendo il WL avvenga solo a causa del GC.

Edit. mi posso dare dello scemo da solo però... quel software controlla la velocità di lettura dei file, prendendo i frammenti sull'ssd ovunque si trovino, e ordinandoli (oltre che per velocità e grandezza), anche per data di creazione. spostando il file per WL la data del file rimane quella. Quindi ho visto/dimostrato... niente (scusate).
Dovrei prendere un software diverso ma non ho idea di quale.

[Tennic]

Originariamente inviato da @Liupen

Che l'OP allunghi la vita del SSD è una panacea inventata per tranquillizzare i consumatori più di una decina di anni fà (lo so vi faccio venire l'ansia ora).

Mi hai sbloccato un ricordo

Anni fa, quando il Crucial M4 era appena uscito (e lo comprai, perchè molto valido) c'era un utente (non faccio nomi ) che preannunciava disastri immani se non si fosse seguita una breve sequenza di ottimizzazioni (35 punti), in base alle quali praticamente Windows 7 diventava Windows 3.1

I temporanei su HD esterno, zero indicizzazione, prefech, superfetch, etc etc, ricordo solo che non finiva mai, e se non si seguivano tali indicazioni, praticamente l'SSD sarebbe durato da Natale a Santo Stefano.
Chi (come me) faceva umilmente presente che non si trattava degli SSD del 2000 e le durate erano ben superiori, veniva tacciato di eretismo, e solo l'epoca non medievale ci (e mi) ha salvato dal rogo

Ebbene, il mio Crucial M4 da 128 GB, comprato nel 2011, ed ora nel pc di mia moglie, ha visto Windows 7, Windows 10 e Windows 11, lavorando come Microsoft ha deciso, quindi con temporanei, indicizzazione, etc, utilizzo standard di windows (documenti su Office e navigazione web), e senza alcun riguardo (installazioni e disinstallazioni software, e zero pulizia temporanei se non con miei rari passaggi su quel pc).

Meno male che quel SSD non sa leggere, e non sa che sarebbe dovuto morire 10 anni fa, infatti è ancora al 85% di vita celle

Originariamente inviato da @Liupen

La spia indica attività sull'interfaccia (vado solo di logica).

Ne ha una la mainboard, ne ha una il box storage esterno.
Quindi a meno che non ce l'abbia l'ssd stesso, direi che il led si illumina per la sola attività dell'host e non del GC/WL

Quoto

Originariamente inviato da @Liupen

Aspetta che c'è una contraddizione nel tuo pensiero.
Se lo spostamento avviene a livello di controller (ed è così), il controller che agisce per gli algoritmi di WL ignora cosa ci sia sulle celle, quindi anche i file che costituiscono l'OS (la parte più vecchia di una installazione), dovrebbero spostarsi.

Però ho sempre avuto l'impressione che ci siano molti dati statici e che lo spostamento seguendo il WL avvenga solo a causa del GC.

Esatto, qual è la contraddizione? Lui sa da quanto tempo una specifica cella non è stata interessata da scritture, quindi decide di spostare il contenuto in altra cella (anche comprese quelle che eventualmente sono state destinate all'OP, e quindi sono sicuramente libere).

Ovviamente, questo è quello che dovrebbe accadere ed ho appreso documentandomi in questi anni, non sono dentro il controller ed il firmware, per sapere cosa accade in realtà

[@Liupen]

Originariamente inviato da Tennic

Mi hai sbloccato un ricordo

Anni fa, quando il Crucial M4 era appena uscito (e lo comprai, perchè molto valido) c'era un utente (non faccio nomi ) che preannunciava disastri immani se non si fosse seguita una breve sequenza di ottimizzazioni (35 punti), in base alle quali praticamente Windows 7 diventava Windows 3.1

I temporanei su HD esterno, zero indicizzazione, prefech, superfetch, etc etc, ricordo solo che non finiva mai, e se non si seguivano tali indicazioni, praticamente l'SSD sarebbe durato da Natale a Santo Stefano.
Chi (come me) faceva umilmente presente che non si trattava degli SSD del 2000 e le durate erano ben superiori, veniva tacciato di eretismo, e solo l'epoca non medievale ci (e mi) ha salvato dal rogo

Ebbene, il mio Crucial M4 da 128 GB, comprato nel 2011, ed ora nel pc di mia moglie, ha visto Windows 7, Windows 10 e Windows 11, lavorando come Microsoft ha deciso, quindi con temporanei, indicizzazione, etc, utilizzo standard di windows (documenti su Office e navigazione web), e senza alcun riguardo (installazioni e disinstallazioni software, e zero pulizia temporanei se non con miei rari passaggi su quel pc).

Meno male che quel SSD non sa leggere, e non sa che sarebbe dovuto morire 10 anni fa, infatti è ancora al 85% di vita celle



Quoto



Esatto, qual è la contraddizione? Lui sa da quanto tempo una specifica cella non è stata interessata da scritture, quindi decide di spostare il contenuto in altra cella (anche comprese quelle che eventualmente sono state destinate all'OP, e quindi sono sicuramente libere).

Ovviamente, questo è quello che dovrebbe accadere ed ho appreso documentandomi in questi anni, non sono dentro il controller ed il firmware, per sapere cosa accade in realtà

Ho editato il messaggio per aggiungere che le tue considerazioni sono giuste. Quel software andava bene in generale per dire che i file vecchi (os) sono lenti in performance, ma non dice che sono stati spostati...quindi inutile

Come fare a constatare se il WL funziona anche per il sistema operativo (uno per tutti) e che le celle si consumino tutte senza dati statici sopra?
Boh!

...Crucial M4, tu hai iniziato prima, penso che quando uscirono io ero alle prese ancora con il velociraptor e i wd black
Il tipo di cui parli per via del bug a momenti ci prendeva sul serio!

Ho un 840 pro vivo al 74% anch'io in un vecchio notebook, ma diciamo che fà il pensionato e non lavora troppo.

[Tennic]

Originariamente inviato da @Liupen

Come fare a constatare se il WL funziona anche per il sistema operativo (uno per tutti) e che le celle si consumino tutte senza dati statici sopra?
Boh!

Questo non lo so purtroppo, essendo una funzione a livello di firmware, è trasparente al sistema operativo e quindi a qualunque software... A rigor di logica, il WL dovrebbe "garantire" che se le celle sono ad esempio al 90%, sono tutte al 90%, appunto grazie al bilanciamento, e non quelle dove c'è un file vecchio e fermo da anni è al 100% (una sola scrittura), e l'altra che magari sta a centro unità* invece è al 10% perchè scrive 1000 volte al giorno

*con gli SSD non esiste inizio centro e fine unità, proprio per il dinamismo delle celle, ovviamente sono numerate, ma quello che ora sta nella cella 1000, dopo può essere spostato dal WL nella cella 1, ma ho usato il termine "centro" per rendere l'esempio

[mtofa]

Sinceramente mi sono sforzato ma non riesco a comprendere a cosa vi servirà conoscere tali dettagli...

[giovanni69]

Domanda: quando un SSD scende ad esempio al 95%, visto che tali celle oggetto ad usura sono individuabili almeno dal fimware, non sarebbe possibile effettuare una sorta di formattazione a basso livello in grado di selezionare le celle ancora buone, escludendo quelle rovinate oltre un certo WL ed ottenere di nuovo il 100%?

(Un po' come accadeva con gli HD ed i blocchi rovinati: una formattazione a basso livello li escludeva e si vedevano le dimensioni del disco scendere leggermente perché i bad blocks erano reasi indisponibili dal totale non allocato).

[@Liupen]

Originariamente inviato da mtofa

Sinceramente mi sono sforzato ma non riesco a comprendere a cosa vi servirà conoscere tali dettagli...

Capire qualcosa che è un meccanismo interno, attraverso un mezzo indiretto; come una sfida. Semplice voglia di conoscenza, fine a se stessa. Passione.


Ti faccio un esempio di un altra cosa che ho scoperto da poco e ha demolito un mio preconcetto.

DirectStorage si stà concretizzando, ed immancabilmente diventa uno spartiacque per lo storage gaming.
Tutti ormai sanno come funziona: i dati letti in piccoli blocchi finiscono su una apposita zona della ram di sistema e sono presi direttamente dalla gpu che li decomprime e li mette sulla vram.

Il fatto che la lettura avvenga dall'API I/0 si scontra col fatto che un nvme abbia velocità 4K casuali basse (relativamente parlando) è simili ad un ssd sata.
Allora mi sono chiesto: perchè prendono dell'nvme proprio l'aspetto più debole?

Ho cercato tra i white paper di microsoft ed ho trovato che la dimensione di questi blocchi è di 64KiB.
Ancora non capivo un file casuale così perchè.. mi sembrava che portasse performance basse rispetto alle prestazioni sequenziali.
Fino a quando ho provato a impostare Crystaldiskmark (un software user banalissimo) con un casuale da 64KiB ad una coda altissima (come in realtà avviene).
Il risultato? Una velocità poco sotto il sequenziale.
Ho imparato da me, con i mezzi a mia disposizione, una cosa in più.

Originariamente inviato da giovanni69

Domanda: quando un SSD scende ad esempio al 95%, visto che tali celle oggetto ad usura sono individuabili almeno dal fimware, non sarebbe possibile effettuare una sorta di formattazione a basso livello in grado di selezionare le celle ancora buone, escludendo quelle rovinate oltre un certo WL ed ottenere di nuovo il 100%?

(Un po' come accadeva con gli HD ed i blocchi rovinati: una formattazione a basso livello li escludeva e si vedevano le dimensioni del disco scendere leggermente perché i bad blocks erano reasi indisponibili dal totale non allocato).

Mi piacerebbe conoscere e capire come si programmano i controller penso rimarrà un mistero cosa si possa fare o no.

Di logica (anche quì) se una cosa del genere una cella consumata resta consumata (non ritornano al 100% perchè cosa le consuma è la perdita di elettroni), quindi per pareggiare puoi solo consumare le altre... in pratica descrivi cosa fà il WL

[giovanni69]

Originariamente inviato da @Liupen

Di logica (anche quì) se una cosa del genere una cella consumata resta consumata (non ritornano al 100% perchè cosa le consuma è la perdita di elettroni), quindi per pareggiare puoi solo consumare le altre... in pratica descrivi cosa fà il WL

Tu dici che io descrivo cosa fa il WL ma se così fosse dovremmo vedere di nuovo il 100% se l'health dipende da esso. Ma in realtà così non avviene. O almeno quell'indicatore scende e non risale dopo l'azione del WL. Oppure voi avete visto che coerentemente con la discesa al 99%..98%...97%..scende la dimensione di un SSD (così come quando una formattazione a basso livello esclude i bad blocks)?

[Tennic]

Originariamente inviato da giovanni69

Tu dici che io descrivo cosa fa il WL ma se così fosse dovremmo vedere di nuovo il 100% se l'health dipende da esso. Ma in realtà così non avviene. O almeno quell'indicatore scende e non risale dopo l'azione del WL. Oppure voi avete visto che coerentemente con la discesa al 99%..98%...97%..scende la dimensione di un SSD (così come quando una formattazione a basso livello esclude i bad blocks)?

Un attimo, il WL non rigenera le celle, semplicemente se ad esempio le celle hanno una vita da 100 scritture, ed una cella ha subito 5 scritture (perchè quel dato viene salvato spesso), quindi 95% di vita residua, ed altre celle sono ad una scrittura (99% di vita residua), il firmware la prossima volta che deve scrivere il primo dato pensa "uso sempre quella cella e la sto consumando, ora lo scrivo in un'altra cella che è a quota una scrittura, così la porto a 2, e lascio in pace quella che è a 5"

Come vedi, non è che il WL rigenera la cella e la vita residua sale di nuovo...
E' come avere due auto, se ne usi sempre una e lasci ferma l'altra, se un giorno decidi di fermare la prima ed usare la seconda per pareggiare i km, non è che la prima ritorna nuova ed al 100%, stai semplicemente pareggiando la seconda alla prima

Quindi la vita residua non è legata ai blocchi danneggiati (quelli sono semplicemente blocchi non disponibili, ed ogni unità, anche HDD, ne hanno vari di riserva) ma a quanti km (scritture) hanno subito le celle, celle che il WL tenta di "pareggiare" nelle scritture, quindi se devo scrivere 1 TB, cerca di spalmarlo su tutte le celle per dividere il lavoro e l'usura

[giovanni69]

Ti ringrazio per il tuo intervento. La mia premessa non era la rigenerazione.

Era quella di affermare: data una certa soglia per cui una cella viene considerata 'bad' perché ha superato una certa soglia d'uso, mi chiedevo se accededendo al livello di WL di ciascuna cella, si potesse riformattare tutto daccapo e selezionare solo le celle ancora 'buone' che superano dunque un certo standard per restituire il 100%, pur diminuendo la dimensione totale disponibile. In termini relativi, cercavo di capire come si passa da un 100% al 99%...se é un problema di numero di celle rovinate / totale; oppure quando.... oppure non ha senso ripristinare il 100% perché una volta ottenuto il 99%, non é possibile ri-selezionare celle per riottenere il 100%, un po' come dire che non si possono ricomporre le uove strapazzate.

[Tennic]

Originariamente inviato da giovanni69

Ti ringrazio per il tuo intervento. La mia premessa non era la rigenerazione.

Era quella di affermare: data una certa soglia per cui una cella viene considerata 'bad' perché ha superato una certa soglia d'uso, mi chiedevo se accededendo al livello di WL di ciascuna cella, si potesse riformattare tutto daccapo e selezionare solo le celle ancora 'buone' che superano dunque un certo standard per restituire il 100%, pur diminuendo la dimensione totale disponibile. In termini relativi, cercavo di capire come si passa da un 100% al 99%...se é un problema di numero di celle rovinate / totale; oppure quando.... oppure non ha senso ripristinare il 100% perché una volta ottenuto il 99%, non é possibile ri-selezionare celle per riottenere il 100%, un po' come dire che non si possono ricomporre le uove strapazzate.

Se il WL funziona bene (SE), tu non avrai celle esaurite e celle al 100%, ma tutte le celle avranno più o meno lo stesso livello di usura, pertanto con l'esempio che fai, potresti selezionare supponiamo le celle che non sono a zero, ma quelle selezionate sono all'1 o 2% (mica al 100%), quindi non so sino a che punto possa valerne la pena continuare ad usare l'SSD solo con le celle che non sono "da buttare"... Quelle che rimangono sarebbero "quasi da buttare"

Il calcolo del 100% o 99% è molto semplice... Supponiamo che ad esempio le celle sono garantite per 1000 scritture (metto un numero a caso), e la dimensione del SSD è 1.000 GB, ecco, la quantità di dati che sarà possibile scrivere prima che l'SSD si esaurisca sarà 1.000x1.000 ossia 1.000 GB (1 TB) scritti 1.000 volte, pertanto 1.000 TB.

Il WL si preoccupa di cercare di spalmare questi 1.000 TB di vita (scritture) totale su tutte le celle, affinchè tutte abbiano pressappoco lo stesso numero di scritture.
Quando "tutte" (se il WL funziona bene) le celle hanno subito 100 scritture (su 1000 di vita totale), allora la vita è scesa al 90%, è così via (1% ogni 10 scritture, quindi ogni 1000x10=10.000 GB = 10 TB scritti.
A 1.000 TB abbiamo "esaurito" le scritture a disposizione, quindi abbiamo fatto il 100%, pertanto 1% è uguale a 10 TB scritti.

Ovviamente le 1000 scritture sono le minime garantite, magari funziona anche per 2000, o 1001, o 1000 spaccate.

Quando la singola cella "muore" (mica sono tutte uguali, è fisicamente impossibile, qualcuna potrebbe durare 1200 scritture, altre 1100 e così via, così come anche un motore non è identico agli altri, cambia sempre qualcosa micrometrica) il controller la "isola", quindi non la usa più, sostituendola con un'altra di riserva, o se quelle di riserva sono finite è giunto il tempo di cambiare l'SSD allora lo spazio totale diminuisce

Spero di aver spiegato più o meno in modo chiaro

[giovanni69]

Chiarissimo, grazie!

[Nicodemo Timoteo Taddeo]

Originariamente inviato da giovanni69

Ti ringrazio per il tuo intervento. La mia premessa non era la rigenerazione.

Era quella di affermare: data una certa soglia per cui una cella viene considerata 'bad' perché ha superato una certa soglia d'uso, mi chiedevo se accededendo al livello di WL di ciascuna cella, si potesse riformattare tutto daccapo e selezionare solo le celle ancora 'buone' che superano dunque un certo standard per restituire il 100%, pur diminuendo la dimensione totale disponibile. In termini relativi, cercavo di capire come si passa da un 100% al 99%...se é un problema di numero di celle rovinate / totale; oppure quando.... oppure non ha senso ripristinare il 100% perché una volta ottenuto il 99%, non é possibile ri-selezionare celle per riottenere il 100%, un po' come dire che non si possono ricomporre le uove strapazzate.

Un momento, una cella al "95% o anche al 10% di scritture" non è una cella rovinata da escludere, è una memoria che è stata più sfruttata delle altre ma non è da buttare. Il firmware continuerà a scriverci perché è una cella buona e funzionante, quello che cerca di fare è di risparmiare le scritture su di essa per equilibrare il consumo delle altre a lei. In questo modo avrai la capienza totale massima possibile in ogni momento della vista dell'SSD. Questo è quello che cerca di fare e deve fare il firmware del dispositivo.

Se mi vendono uno SSD da 1TB e lo pago con soldi buoni, non mi andrebbe per niente bene che dopo un po' diventi da 995 GB, poi 990, 985, 980 e così via. Io lo voglio sempre da 1 TB fin quando tecnicamente è possibile.

[DMD]

Pensavo che il programma di terze parti come Teracopy, che sempre urtilizzato, andasse bene anche con M2, invece ho dovuto ricredermi, anche con l'ultima versione 3.9.7. Non riesce a trasferire piu di 800Mb/s contro l'explorer, e non riesco a capire il perchè.

[Nicodemo Timoteo Taddeo]

Originariamente inviato da DMD

Pensavo che il programma di terze parti come Teracopy, che sempre urtilizzato, andasse bene anche con M2, invece ho dovuto ricredermi, anche con l'ultima versione 3.9.7. Non riesce a trasferire piu di 800Mb/s contro l'explorer, e non riesco a capire il perchè.

Dubito molto che Teracoopy possa avere influenzata la sua attività in base al tipo di dispositivo di archiviazione, cioè non penso che cambi qualcosa tra NVMe o altri dischi. Se vuoi fare una comparazione dovresti effettuare una copia dello stesso file dallo stesso supporto di origine allo stesso supporto di destinazione.

Nelle immagini che hai postato si vede che la destinazione è la stessa ma non si capsice se la partizione di origine della copia è la stesse, inoltre il file è totalmente diverso. Da una parte un gruppo di 223 file e nell'altra 229 file. Tra l'altro in quel momento Esplora File sta copiando una .iso di grandi dimensioni, cioè attività sostanzialmente sequenziale. Il test non mi sembra probante per così dire.

[DMD]

Originariamente inviato da Nicodemo Timoteo Taddeo

Dubito molto che Teracoopy possa avere influenzata la sua attività in base al tipo di dispositivo di archiviazione, cioè non penso che cambi qualcosa tra NVMe o altri dischi. Se vuoi fare una comparazione dovresti effettuare una copia dello stesso file dallo stesso supporto di origine allo stesso supporto di destinazione.

Nelle immagini che hai postato si vede che la destinazione è la stessa ma non si capsice se la partizione di origine della copia è la stesse, inoltre il file è totalmente diverso. Da una parte un gruppo di 223 file e nell'altra 229 file. Tra l'altro in quel momento Esplora File sta copiando una .iso di grandi dimensioni, cioè attività sostanzialmente sequenziale. Il test non mi sembra probante per così dire.

Il test è stato effettuto con gli stessi file, e stessa identica sorgente e destinazione tra due M2

[Nicodemo Timoteo Taddeo]

Originariamente inviato da DMD

Il test è stato effettuto con gli stessi file, e stessa identica sorgente e destinazione tra due M2

OK, non capisco il perché dei 223 da una parte e 229 dall'altra, o 44GB e 56 GB da una parte ne dall'altra... Secondo me non sono esattamente gli stessi file.

Ad ogni modo non avevo visto che Esplora File è ancora all'inizio (20%) e Teracopy invece al 43%. Probabilmente Esplora file sta ancora scrivendo sulla veloce cache?

Oppure effettivamente TeraCopy ha una modalità di copia file che male si adatta al funzionamento dell'SSD. Sarebbe meglio però a questo punto rifare tutto, cioè copia degli stessi file da e sugli stessi dispositivi ma usando un cronometro, al di là delle indicazioni di scrittura che vedi sul monitor.

[makka]

Originariamente inviato da Nicodemo Timoteo Taddeo

Dubito molto che Teracoopy possa avere influenzata la sua attività in base al tipo di dispositivo di archiviazione, cioè non penso che cambi qualcosa tra NVMe o altri dischi. Se vuoi fare una comparazione dovresti effettuare una copia dello stesso file dallo stesso supporto di origine allo stesso supporto di destinazione.

Nelle immagini che hai postato si vede che la destinazione è la stessa ma non si capsice se la partizione di origine della copia è la stesse, inoltre il file è totalmente diverso. Da una parte un gruppo di 223 file e nell'altra 229 file. Tra l'altro in quel momento Esplora File sta copiando una .iso di grandi dimensioni, cioè attività sostanzialmente sequenziale. Il test non mi sembra probante per così dire.

Originariamente inviato da DMD

Il test è stato effettuto con gli stessi file, e stessa identica sorgente e destinazione tra due M2

E' strano quello che dici, dagli screenshots anche io capisco quello che ha detto Nicodemo Timoteo Taddeo.
Sembra che explorer copi la iso cosi com'è, mentre teracopy spacchetti la iso e copi il singolo file.
"install.wim" è uno dei file più grandi (o forse il più grande) contenuto in uno iso di installazione di windows

[DMD]

Ho ripetuto il test per essere più comprensibile a tutti.
Ho copiato altra cartella, identica per i due test, con queste proprietà:







TeraCopy


Explorer