@
giolupo, riguardo a cosa hai scritto e riportato sulla deframmentazione degli SSD, ho qualcosa da dire...
Innanzitutto gli SSD non hanno bisogno di essere deframmentati.
Proprio come struttura, per via del software interno (GC) sposta da se i blocchi, come sappiamo, a seguito della cancellazione dei file da parte del sistema operativo (TRIM).
Dicendolo in termini semplici, cancello un file, e conseguentemente il GC dell'SSD sposta tutti i blocchi attorno per fare in modo che ci si ritrovi con meno "buchi" fra i blocchi (pagine non piene).
Contemporaneamente lo stesso software agisce operando un livellamento dell'usura delle celle (Wear Leveling).
I dati sui blocchi sono sistemati secondo questi principi, indipendentemente dalla frammentazione creata... anzi, paradossalmente, più frammenta i dati, e più celle livellate ci sono, più il GC fà bene il suo lavoro.
Deframmentare poi, spostando i blocchi, cluster... chiamiamoli come si vuole, vuol dire la riscrittura di buona parte dei dati, secondo un principio di contiguità, "consumandole".
E poi, spostare i dati su blocchi contigui significa andare contro il Wear Levelling, quindi doppiamente negativo.
Dire che gli SSD non hanno bisogno di deframmentazione, mi dirai, non vuol dire che (come hai riportato), non ne traggano beneficio.
Però riflettiamo..
La scrittura sulle celle avviene perchè queste sono state prima cancellate dai valori che avevano. Il fattore che determina questa condizione è: cella vergine o cella che è stata cancellata a seguito di un comando di P/E.
Il primo caso si ha fino al termine del 1° ciclo e dopo sulle celle interstiziali rimaste.
Il secondo caso si ha quando TRIM è attivo, ed il GC dell'SSD ha liberato spazio.
Visto che solo il secondo caso è la condizione normale d'uso, direi che le performance di scrittura di un SSD dipendono dall'efficacia del TRIM e del GC interno dell'SSD (più gli altri fattori come la cache, ecc che adesso non considero).
In tutto questo meccanismo la deframmentazione non porta miglioramenti...
MA
Windows 8, diversamente da Windows 7, riconoscendo un drive SSD, imposta una ottimizzazione che molti credono sia la stessa operata su un hdd e che consiste nella deframmentazione programmata.
Microsoft stessa - dopo il bug di gestione - ha puntualizzato che è un'attivazione forzata del comando TRIM, indipendente dall'attivazione richiesta, solo quando necessaria, da parte del firmware dell'SSD.
In effetti l'ottimizzazione programmata di Windows 8 (TRIM), per il discorso di cui sopra, giova all'SSD. ;)
La lettura delle celle (ricordo che non avviene con un meccanismo come per gli HDD), semplicemente accade perchè il controller (la CPU dell'SSD) che gestisce un caos di dati apparente, interpreta il segnale e lo ripropone sulla RAM del nostro PC.
Cosa può rallentare la lettura?
La qualità e potenza del controller, la qualità del segnale presente sulla cella, la coda di lettura (quindi le letture parallele operate dal controller), il controller impegnato in azioni di GC aggressive.
A differenza dei dati che mi mostri, io non credo che un fattore di rallentamento della lettura sia il fatto che i blocchi si trovino vicini o in posizione lontana fra di loro.
Il controller legge un indice che gli dice dove sono memorizzati i blocchi che formano un file... quindi li prende e ce li ripropone... che importa se sono in posizione (invento) 4-5-6, piuttosto che 10-108-2045.
Piuttosto, se la correlazione (non so con che software fatta) è corretta, andrei a ricercare la causa nel miglioramento dela qualità del bit, e nel minor carico di GC, effettuata a seguito (o a causa della deframmentazione).
Sembra chiaro che a migliorare le prestazioni non è la deframmentazione dell'SSD, e che questa porta tanti aspetti negativi e nessuno positivo.
