magari è anche peggio: se ipotizzi che lo spazio non allocato non possa essere mai scritto (dal wear levelling) ma resta solo come overprovision (cioè per sostituire le celle "morte") tutte le scritture avvengono sempre nello spazio allocato che è minore perciò più stressato. Ipotesi mia eh, non verità. Non so se la logica del w-l sia la stessa del o-p o meno. Tantomeno i vari trim e g-c che credo siano gestiti dal s.o. quindi forse "vedono" solo le partizioni. Boh.
A quanto dicono loro sembra indifferente.

Questo no, perchè il firmware effettua un bilanciamento dell'utilizzo delle celle (wear leveling), cosa del tutto trasparente al sistema operativo e quindi anche all'utente.
In altre parole, quando un dato viene sovrascritto e quindi sostituito, viene messo in un'altra cella.
Ed anche i dati statici vengono periodicamente spostati.

Come si diceva, l'OP manuale (dedicare spazio non partizionato) è come un salvadanaio, uno potrebbe avere i soldi nel portafoglio ma non usarli (ma la tentazione magari c'è), ma se li mette nel salvadanaio è sicuro che non può usarli neanche per sbaglio, scusate il paragone ma rende l'idea :D

L'esigenza di destinare dello spazio disco appositamente per l'over provisoning è nata ed aveva senso con le prime unità SSD, quando le dimensioni dei tagli in commercio erano molto piccole. 64-128 GB tipicamente, con dispositivi di quella capacità ci stava facilmente che l'utente anche inconsapevolmente li riempisse. Inconsapevolmente perché lo stesso Windows malgestito può sprecare giga e giga di spazio disco. Quindi meglio prevedere e prevenire destinando in partenza una quota disco all'uso OP.

Oggi penso che nessuno compri SSD con dimensione minore di 512 GB, il rischio di riempirli a tappo è molto minore di una volta, inoltre già i produttori prevedono un quantitativo di memoria riservato per l'OP del tutto trasparente e non accessibile e sfruttabile dall'utente.

Dal punto di vista dell'ssd, delle celle/controller, lasciare uno spazio raw o lasciare spazio libero in una partizione, è uguale. Il controller sa che potrà usare quelle celle per spostare i dati (quindi tutto WL e GC).

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).
L'OP serve a far si che un sistema operativo installato sia gestibile prima che l'ssd diventi inusabile.
Pensateci con un esempio: avete tra le mani un ssd teorico con 10 celle; prima o poi tutte si consumeranno giusto? Che io abbia una partizione di 10 celle ma ne usi solo 8 o che abbia una partizione di 8 celle e un OP di 2 celle, sempre 10 celle ho... quindi un ssd durerà quanto durano 10 celle.
La differenza la può fare se su quel ssd ho un OS.
Ben prima dello spegnimento delle celle un OS in un ssd in crisi, avrà dei BSoD. Quindi il fatto di avere celle "sicuramente" fuori dallo spazio utente (una volta gli ssd erano piccoli e il loro riempimento era un dato di fatto), permette una riallocazione dei blocchi "sicuramente" possibile e consente all'utente di usare più a lungo il sistema operativo.

Oggi è possibile fare a meno dell'OP.
Vale la regola del "non riempirlo completamente", anche per far funzionare bene la cache SLC.
C'è inoltre sempre un OP di fabbrica.

Come si diceva, l'OP manuale (dedicare spazio non partizionato) è come un salvadanaio, uno potrebbe avere i soldi nel portafoglio ma non usarli (ma la tentazione magari c'è), ma se li mette nel salvadanaio è sicuro che non può usarli neanche per sbaglio, scusate il paragone ma rende l'idea [cit.]
Ahahaha! Si rende bene l'idea.

Ho lanciato un SSD Read Speed Tester (che Giovanni conosce bene) sul mio laptop con 1 anno di installazione OS, a proposito del

Ed anche i dati statici vengono periodicamente spostati [cit]

quindi sono andato a vedere i giorni di creazione dei file e per poco meno della metà risalgono ad oltre la data di installazione.
Non che sia una prova ma lascia dei dubbi sull'efficacia in generale del WL.

Nocodemo: avevo da un po la pagina aperta e non ho visto la tua risposta, che in pratica dice la stessa cosa vera.

Se parli di ssd da assemblare noi ok, ma nei portatili economici ce n'è spessissimo uno da 256, e anche in quelli meno economici (Mac Air base 8+256).
Poi spesso ci sono quelli vecchi sono da riciclare. Comunque col peso dei giochi ormai su 50GB l'uno anche 512 non sono tantissimi.

Ok mi avete convinto....tolgo l'OP di 10gb che avevo assegnato su entrambi i miei drives.

Tanto io non riempio mai gli ssd. :fagiano:

Wear Leveling su SSD e.... indicatore LED
 

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

Infatti per questo chiedevo lumi sulla qualità e la durata... a trovare i benchmark in giro per la rete c'è l'imbarazzo della scelta, ma notizie sulla qualità dei componenti interni pochine... oppure sono io che non ci capisco niente!

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

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

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.

Mi hai sbloccato un ricordo :D

Anni fa, quando il Crucial M4 era appena uscito (e lo comprai, perchè molto valido) c'era un utente (non faccio nomi :D ) 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 :D

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 :D

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 :D

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à :D

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

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

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

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

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



Mi piacerebbe conoscere e capire come si programmano i controller :D 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

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" :D

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

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.