Perché SSD e chiavette USB rallentano durante copie molto lunghe

Avviare la copia di un file da 100 o 200 GB su un SSD può produrre un comportamento apparentemente inspiegabile: nei primi secondi Windows mostra 1,5 GB/s, 2 GB/s o anche di più, poi la velocità precipita a poche centinaia di MB/s. Su alcune unità economiche può scendere addirittura sotto i 100 MB/s. Con le chiavette USB lo scenario può risultare ancora più evidente: un dispositivo di memorizzazione che, sulla carta, dovrebbe scrivere al ritmo di centinaia di MB/s può partire molto velocemente e poi stabilizzarsi su valori drasticamente inferiori.

Molti dispositivi dotati di memoria flash sono progettati proprio per fornire prestazioni molto elevate per brevi raffiche di scrittura, sfruttando cache veloci; quando però la copia prosegue abbastanza a lungo, emerge la velocità reale della memoria NAND sottostante. A quel punto entrano in gioco anche garbage collection, quantità di spazio libero, temperatura, controller, DRAM e tipo di NAND utilizzata.

Le memorie NAND non si comportano come la RAM

Un’unità SSD non memorizza i dati semplicemente sovrascrivendo una cella ogni volta che Windows richiede un’operazione di scrittura.

La memoria NAND Flash organizza i dati in pagine, cioè piccoli gruppi di celle che rappresentano l’unità minima normalmente programmata o letta. Più pagine formano poi un blocco, molto più grande. Una singola pagina già usata non può essere semplicemente cancellata da sola: per recuperare quello spazio il controller deve cancellare l’intero blocco che la contiene, dopo aver eventualmente spostato altrove le pagine ancora valide.

Sui dispositivi NAND, compresi SSD, chiavette USB e schede SD, non è insomma possibile sovrascrivere direttamente un dato nella stessa posizione come avviene concettualmente con un disco magnetico. Il controller deve recuperare le pagine ancora valide, raggruppare lo spazio riutilizzabile e cancellare i blocchi prima di poterli programmare nuovamente. È il lavoro svolto dalla garbage collection.

Per nascondere questa complessità al sistema operativo, ciascun SSD contiene un controller che mantiene una mappatura tra indirizzi logici richiesti dal PC e posizioni fisiche nella NAND. Finché esistono molte pagine libere, tutto può avvenire molto velocemente. Durante una scrittura continua, però, il margine di manovra diminuisce.

Il trucco principale: usare TLC e QLC come se fossero SLC

Molti SSD consumer utilizzano NAND TLC o QLC. In termini semplificati, un’unità con memorie SLC conserva 1 bit per cella; una MLC 2 bit per cella, una TLC 3 bit, una QLC 4 bit. Aumentare il numero di bit memorizzati per cella riduce il costo per gigabyte e aumenta la densità, ma rende la programmazione delle celle più complessa. Ne abbiamo parlato in un articolo incentrato sugli SSD QLC (quad-level cell).

Per ottenere velocità elevate, i produttori utilizzano quindi una parte della NAND TLC o QLC in una modalità che si comporta sostanzialmente come SLC.

SanDisk descrive per esempio la propria tecnologia nCache come una cache SLC composta da una parte fissa e una parte dinamica ricavata dallo spazio NAND non occupato. I dati vengono scritti prima nella cache veloce e successivamente trasferiti nella NAND più densa attraverso un’operazione di consolidamento eseguita preferibilmente nei periodi di inattività.

Osservando “da fuori”, il PC vede una cache SLC molto veloce affiancata da memorie NAND TLC/QLC più lente: questo è il segreto dietro molte velocità di scrittura spettacolari dichiarate sulle schede tecniche di tanti prodotti.

Finché la cache non è piena tutto vola

Supponiamo che un SSD QLC possa scrivere nella sua cache SLC a 2.500 MB/s ma che la NAND QLC, una volta programmata direttamente, riesca a sostenere soltanto 300 MB/s. Copiando 5 GB, l’utente potrebbe non accorgersi mai della differenza. Perché? Perché il trasferimento dati finisce mentre la cache è ancora disponibile.

Con un file da 200 GB, invece, la cache si riempie e il grafico che in Esplora file riflette le prestazioni del trasferimento in corso può mostrare un vero e proprio gradino. La velocità non diminuisce gradualmente perché l’SSD “si sta stancando”: semplicemente ha terminato lo spazio utilizzato come buffer.

Due o più SSD pubblicizzati come PCIe 4.0 possono quindi comportarsi in maniera completamente diversa dopo i primi gigabyte.

La cache SLC non ha necessariamente dimensioni fisse: come accennato in precedenza, molti controller ricavano una parte della cache dallo spazio NAND ancora libero. Se l’SSD è quasi vuoto, può disporre di una cache molto ampia; quando l’unità si riempie vi è evidentemente poca NAND disponibile per la cache SLC. Una stessa copia può quindi comportarsi diversamente sulla medesima unità a distanza di mesi.

Avere poco spazio libero rende più difficile anche il lavoro interno del controller, che dispone di meno blocchi liberi da utilizzare durante garbage collection e wear leveling: è uno dei motivi per cui lasciare un certo margine di spazio libero su un SSD può contribuire alla regolarità delle prestazioni.

Mantenere spazio disponibile a sufficiente in un’unità SSD non è quindi un falso mito: ne abbiamo parlato anche nell’articolo su cosa conta davvero per far durare di più gli SSD.

Cosa succede mentre l’SSD svuota la cache

La cache non può e non deve trattenere i dati a lungo termine: il controller deve trasferirli verso la NAND TLC o QLC. Idealmente lo fa quando l’unità è poco impegnata ma, com’è facile intuire, una copia file molto lunga elimina i periodi di pausa utilizzabili per questo fine.

Il PC continua a mandare dati mentre il controller deve contemporaneamente ricevere e gestire le nuove scritture, svuotare la cache SLC, programmare TLC/QLC ed eseguire la garbage collection.

Se arrivano 2 GB di dati al secondo ma la NAND TLC/QLC riesce a smaltirli soltanto al ritmo di 400 MB/s, prima o poi il buffer va a saturarsi e la velocità rilevata dall’utente scenderà in modo verticale.

Garbage collection e write amplification

La stessa garbage collection, come spiegato in precedenza, non presuppone la possibilità di sovrascrivere semplicemente le pagine non più in uso. Il controller, per recuperare spazio, può dover leggere più pagine valide, copiarle in un altro blocco, cancellare l’intero blocco originale per poi renderlo nuovamente disponibile. È un lavoro che non corrisponde necessariamente a dati che Windows ha esplicitamente chiesto di scrivere. Di conseguenza, un trasferimento da 100 GB può quindi causare internamente più di 100 GB di scritture NAND!

Il rapporto fra ciò che il sistema operativo chiede di scrivere e ciò che il controller deve effettivamente programmare prende il nome di Write Amplification Factor, WAF.

Se Windows scrive 100 GB e l’SSD, tra spostamenti e garbage collection, scrive fisicamente 150 GB, WAF è 1,5.

La write amplification incide sia sulle prestazioni sia sull’usura della memoria NAND; il fenomeno – come già evidenziato – tende inoltre a peggiorare quando l’unità dispone di poco spazio libero.

Perché le chiavette USB possono rallentare ancora di più

Le chiavette USB utilizzano anch’esse memoria NAND Flash, ma generalmente dispongono di controller molto più semplici rispetto a un buon SSD.

Una chiavetta USB 3.x potrebbe disporre teoricamente di un collegamento capace di muovere centinaia di MB/s ma usare memorie NAND in grado di sostenere soltanto 30-80 MB/s quando termina la piccola cache iniziale.

È quindi fondamentale distinguere la velocità dell’interfaccia USB dalla velocità reale della memoria flash: un collegamento USB a 5 Gbps non significa che il dispositivo riesca a scrivere a 625 MB/s. Quella è la capacità teorica del collegamento, peraltro prima degli overhead del protocollo; la NAND e il controller possono costituire un collo di bottiglia molto più stretto.

SanDisk cita tra le cause delle basse prestazioni delle unità USB anche porta, hub, adattatore, cavo, file system, spazio libero, quantità di piccoli file e temperatura.

Velocità dichiarata, NAND e temperatura: perché i numeri cambiano

La velocità riportata sulla confezione dell’unità di memorizzazione non coincide quasi mai con la scrittura sostenuta: spesso il valore più alto riguarda la lettura sequenziale o una breve fase in cui interviene la cache pseudo-SLC.

Per questo un’unità può leggere a 400 MB/s ma scrivere stabilmente a 80 MB/s, oppure partire a 2-3 GB/s e poi scendere quando deve programmare direttamente la NAND TLC o QLC.

In genere la TLC mantiene prestazioni native superiori alla QLC, ma contano anche controller, numero di canali, quantità di die NAND e capacità dell’unità: versioni più capienti dello stesso SSD possono essere più veloci perché sfruttano maggiore parallelismo e spesso dispongono di una cache dinamica più ampia.

La DRAM del controller, inoltre, non va confusa con la cache SLC: serve soprattutto a gestire rapidamente le tabelle di mappatura tra indirizzi logici e celle fisiche; gli SSD DRAM-less possono comunque avere cache SLC e, nel caso degli NVMe, usare HMB (Host Memory Buffer) sfruttando una piccola porzione della RAM di sistema.

Durante le scritture prolungate entra poi in gioco la temperatura: controller NVMe, NAND e bridge USB possono scaldarsi abbastanza da attivare il thermal throttling, riducendo deliberatamente il throughput. Per questo lo stesso SSD può sostenere velocità differenti con o senza dissipatore, dentro un enclosure compatto oppure con temperature ambientali diverse.

Non sempre è l’SSD: file piccoli, sorgente e interfaccia possono diventare il collo di bottiglia

Una copia di un singolo file da 100 GB è molto più favorevole di un trasferimento composto da centinaia di migliaia di file piccoli: in quest’ultimo caso aumentano aperture e chiusure, metadati, accessi non sequenziali, aggiornamenti delle directory e controlli dell’antivirus, tanto che il throughput può scendere drasticamente pur con una NAND molto veloce.

Bisogna inoltre considerare l’intera catena I/O: un SSD da 3 GB/s non può ricevere dati più rapidamente di un hard disk che legge a 150 MB/s, né un NAS può superare i limiti imposti da rete, SMB e dischi sorgenti.

Lo stesso vale per USB: 5, 10 o 20 Gbps, USB4 e Thunderbolt indicano la capacità massima del collegamento, non quella della memoria.

Un SSD NVMe da 7 GB/s inserito in un enclosure USB 10 Gbit/s viene limitato dall’interfaccia; al contrario, se un SSD esterno collegato a 10 Gbps scende da 900 a 300 MB/s dopo molti gigabyte, il limite può essere diventato la NAND o la cache esaurita, non l’interfaccia USB.

In pratica, la velocità osservata durante una copia è sempre quella del componente più lento in quel preciso momento.

Come capire se il problema è la cache SLC

Il metodo più semplice consiste nell’osservare la forma del trasferimento. Un comportamento tipico è:

0-20 GB 1.800 MB/s
20-200 GB 350 MB/s

Il passaggio netto dopo una determinata quantità di dati è un forte indizio dell’esaurimento della cache. Ripetendo il test immediatamente, senza dare all’SSD il tempo di effettuare il folding della cache, le prestazioni potrebbero partire già più basse.

Lasciando invece il computer inattivo per qualche minuto, il controller può completare parte del lavoro interno e la velocità iniziale elevata può ricomparire. Proprio questo comportamento è uno degli indizi più evidenti della presenza di una cache di scrittura NAND.

Come riconoscere il thermal throttling

Il thermal throttling tende a correlarsi maggiormente con tempo e temperatura. Potremmo rilevare, ad esempio, qualcosa di simile senza un confine netto legato alla quantità di cache:

0 min 2.500 MB/s
2 min 2.500 MB/s
4 min 1.700 MB/s
6 min 900 MB/s

Per verificarlo è possibile utilizzare strumenti che leggono i dati SMART/NVMe dell’unità e osservare contemporaneamente temperatura e velocità. Se il throughput risale dopo aver lasciato raffreddare il dispositivo, la componente termica diventa molto probabile.

Il Task Manager di Windows restituisce molti indizi

In Windows 11 basta aprire il Task Manager (Gestione attività, in italiano), ad esempio premendo la combinazione di tasti CTRL+MAIUSC+ESC, quindi accedere alla sezione Prestazioni, Disco. In questo modo è possibile osservare velocità di lettura, velocità di scrittura, tempo di attività, tempo medio di risposta e capacità.

Durante una copia lunga è istruttivo osservare cosa accade quando la velocità precipita.

Se l’unità SSD restasse al 100% in termini di tempo di attività ma trasferisse soltanto poche centinaia di MB/s, significa che l’unità è ancora completamente impegnata e non è in grado di elaborare le scritture più velocemente. Non è Windows che ha deciso di rallentare la copia.

Il rallentamento non si verifica sempre: dipende da come è costruita l’unità

È importante chiarirlo bene: non tutti gli SSD e non tutte le chiavette USB rallentano in modo evidente durante una copia di file molto lunga.

Il comportamento dipende da come l’unità riesce a trasformare un flusso continuo di scritture in operazioni fisiche sulla NAND. Entrano in gioco il tipo di memoria utilizzata, il numero di canali NAND disponibili, il controller, l’eventuale DRAM, la dimensione della cache pseudo-SLC e la quantità di spazio libero.

Un SSD TLC di fascia alta, per esempio, può distribuire le scritture su più die NAND in parallelo e mantenere una velocità elevata anche dopo l’esaurimento della cache. Un modello QLC economico o una chiavetta USB possono invece avere meno parallelismo e una NAND nativa molto più lenta: finché i dati finiscono nella cache SLC le prestazioni sembrano ottime, ma una volta saturata la cache il controller deve programmare direttamente le celle TLC o QLC, operazione più lenta perché richiede di distinguere un numero maggiore di livelli di carica elettrica per ogni cella.

A ciò si aggiunge il lavoro interno necessario per liberare spazio. Se l’unità dispone di pochi blocchi liberi, il controller può dover spostare pagine ancora valide, cancellare interi blocchi e riscrivere dati prima di accogliere nuove scritture (garbage collection/write amplification delle quali abbiamo parlato prima).

Come detto, conta infine anche la velocità della sorgente. Se si copia da un hard disk che legge a 150 MB/s verso un SSD capace di sostenere 500 MB/s anche fuori dalla cache, il drive di destinazione non viene mai messo abbastanza sotto pressione da mostrare il problema.

Il rallentamento va quindi interpretato come un comportamento possibile in determinate condizioni, NON come una caratteristica inevitabile di tutte le memorie flash.

Come capire davvero da dove arriva il rallentamento: test pratici con DiskSpd

Quando una copia file è lenta, il rischio è attribuire immediatamente il problema all’unità di destinazione. In realtà, la velocità complessiva dipende dall’intera catena: sorgente, filesystem, cache, stack I/O di Windows, interfaccia, controller e NAND della destinazione. Un SSD esterno che durante una copia sembra fermarsi a 250-300 MB/s può in realtà essere capace di scrivere molto più velocemente; il collo di bottiglia potrebbe ad esempio trovarsi semplicemente nel disco sorgente.

Per fare un’analisi attendibile conviene quindi misurare separatamente la capacità di lettura della sorgente e quella di scrittura della destinazione, usando un carico semplice e ripetibile. Uno strumento molto utile è DiskSpd, benchmark sviluppato da Microsoft e pensato proprio per generare workload I/O controllati (download).

Misurare la velocità reale di scrittura dell’unità di destinazione

Per verificare quanto un SSD o una chiavetta riescano a scrivere in modo sequenziale, senza essere limitati dalla velocità del disco sorgente, si può creare un file di test direttamente sull’unità da misurare (la lettera di unità F: va ovviamente sostituita con quella corretta):

diskspd -c100G -d300 -Sh -w100 -b1M -o1 -t1 F:\TEST.dat

Le opzioni significano quanto segue:

• -c100G crea un file di test da 100 GB
• -d300 esegue il test per 300 secondi
• -Sh disabilita la cache software e usa write-through
• -w100 genera il 100% di operazioni in scrittura
• -b1M usa blocchi sequenziali da 1 MB
• -o1 mantiene una sola richiesta I/O outstanding
• -t1 utilizza un solo thread

Un test del genere evita un aspetto fondamentale della normale copia di file: DiskSpd genera direttamente il flusso di scrittura, quindi non deve prima leggere centinaia di megabyte al secondo da un’altra unità.

Analisi dei risultati

L’utilità restituisce un’informazione molto più significativa del valore osservato durante una normale copia da Esplora file: può ad esempio mostrare che il dispositivo è perfettamente capace di sostenere oltre 650 MB/s di scrittura e che una copia a velocità inferiori non può essere attribuita all’unità di destinazione.

È importante però interpretare correttamente il risultato del test. Con -c100G e una durata di 300 secondi, se il drive scrive più di 100 GB, DiskSpd ricomincia a operare sulle regioni del file già create. Il test misura quindi molto bene la scrittura sequenziale sostenuta nel tempo, ma non consente da solo di stabilire con precisione dopo quanti gigabyte di dati completamente nuovi si esaurisca una eventuale cache pseudo-SLC.

Misurare separatamente la velocità del disco sorgente

Il secondo passo consiste nel testare il file originale senza coinvolgere l’unità di destinazione. Se, per esempio, il file da copiare fosse C:\TEMP\WIN11.ISO, si può eseguire:

diskspd -d30 -Sh -w0 -b1M -o1 -t1 -L "C:\TEMP\WIN11.ISO"

• -w0 significa 0% scritture e quindi 100% letture
• -L aggiunge le statistiche sulla latenza.

Il file non viene modificato: DiskSpd lo legge sequenzialmente e misura quanto velocemente l’unità C: riesce realmente a consegnare i dati. In alcuni casi si potrebbe rilevare che la capacità di scrittura della destinazione risulta molto più elevata rispetto alla capacità di lettura della sorgente.

Perché Esplora file mostra crolli e successive risalite

Durante la copia reale capita spesso di rilevare velocità che scendono repentinamente durante il trasferimento dei dati, per poi riprendersi. Si tratta di profili che non somigliano molto al classico esaurimento di una cache SLC.

Comportamenti del genere possono manifestarsi quando una lettura della sorgente accumula latenza e i buffer disponibili cominciano a svuotarsi. Anche eventuali picchi di latenza possono temporaneamente interrompere il flusso perché la richiesta successiva non può partire finché quella corrente non risulta completa.

Da non trascurare anche il fatto che se si copia dati da un’unità di sistema, questa potrebbe essere contemporaneamente impegnata in altre attiva: accesso al Registro di sistema, servizi Windows, browser e applicazioni, file temporanei, paging, antivirus, telemetria e log. Il controller dell’SSD deve quindi alternare la lettura sequenziale del file con altre richieste.

Anche il firmware del drive sorgente può svolgere attività interne quali garbage collection, wear leveling, aggiornamento dei metadati e via dicendo.

Come usare Robocopy per ridurre l’effetto della cache di Windows

Per rendere il confronto più significativo si può utilizzare anche robocopy con l’opzione /J, che abilita I/O non bufferizzato, particolarmente utile con file grandi. Per esempio:

robocopy C:\TEMP F:\ WIN11.ISO /J

Anche con un singolo file molto grande robocopy /J può essere sensibilmente più veloce di Esplora file: Microsoft lo raccomanda esplicitamente per i file di grandi dimensioni.

Robocopy evita infatti di far transitare la copia attraverso la normale cache software del file system, nello stesso modo usato da una copia standard. Questo può ridurre copie intermedie in RAM, pressione sulla cache, flush e altre inefficienze che diventano più evidenti con file da molti gigabyte.

Velocizzare la copia di file di piccole dimensioni grazie al multi-threading

Il vantaggio rispetto a Esplora file è evidente soprattutto con molti file di piccole dimensioni. Una copia tradizionale tende a procedere in modo più seriale: apre un file, lo legge, lo crea sulla destinazione, aggiorna i metadati e passa al successivo.

Con il comando robocopy /MT:n, invece, più file possono essere trasferiti contemporaneamente. Microsoft spiega che questo aumenta la quantità di dati “in volo” e riduce le pause nel flusso; il valore predefinito è 8 thread e si può salire fino a 128, anche se un numero troppo elevato può peggiorare le prestazioni.

La copia di file con l’istruzione seguente può risultare nettamente più rapida di una normale copia da Esplora file se la cartella contiene migliaia di file e sorgente e destinazione dispongono di sufficiente I/O:

robocopy C:\Dati F:\Backup /E /MT:16 /R:1 /W:1

Il test più attendibile: osservare sorgente e destinazione insieme

Per un’indagine ancora più rigorosa si può utilizzare Performance Monitor, utilità integrata in Windows avviabile premendo Windows+R quindi digitando perfmon.

Registrando in contemporanei per l’unità sorgente e quella di destinazione contatori come Byte letti da disco/sec, Byte scritti su disco/sec, Media secondi/lettura disco, Media secondi/scrittura disco, Lunghezza coda disco corrente, è possibile mettere in correlazione il comportamento dei due device.

Se durante un rallentamento osserviamo decrescere i Byte letti da disco/sec e aumentare la Media secondi/lettura disco sull’unità di origine e, simultaneamente, il valore Byte scritti su disco/sec diminuire lato destinazione, abbiamo una forte evidenza che la destinazione sta rallentando perché non riceve abbastanza dati dalla sorgente.

Al contrario, se sull’origine la lettura rimane elevata mentre sulla destinazione la latenza di scrittura sale e il throughput precipita, allora l’attenzione deve spostarsi sul drive verso il quale si stanno copiando i dati.

Conclusioni

Le prestazioni osservate durante una copia non dipendono mai da un solo numero riportato sulla confezione dell’SSD.

Cache pseudo-SLC, tipo di NAND, controller, temperatura, spazio libero e attività interne dell’unità possono modificare sensibilmente la velocità sostenuta; allo stesso tempo, il vero collo di bottiglia può trovarsi nella sorgente, nel collegamento o nel modo in cui Windows gestisce il trasferimento.

Per capire cosa sta realmente succedendo conviene quindi misurare separatamente lettura e scrittura, confrontare i risultati con una copia reale tramite Robocopy e, nei casi dubbi, osservare contemporaneamente sorgente e destinazione con Performance Monitor.

Solo così un improvviso calo da centinaia di MB/s può essere attribuito con una certa affidabilità alla cache esaurita, al thermal throttling oppure semplicemente a un flusso di dati che non arriva abbastanza velocemente.