Vai al contenuto
Offerte

Windows, perché copiare tanti file piccoli è così lento

In questo articolo Indice dei contenuti 3 sezioni

Chi ha provato a copiare migliaia di piccoli file su Windows conosce bene quella sensazione strana: un SSD che poco prima aveva spostato un file da 100 GB in pochi minuti, all’improvviso sembra arrancare davanti a una cartella della stessa identica dimensione, composta però da centinaia di migliaia di elementi. I dati sono gli stessi, 100 GB, eppure i tempi si dilatano in modo impressionante. Il motivo non ha quasi nulla a che vedere con la velocità pura dell’unità, ma con tutto il lavoro che sistema operativo e file system devono sbrigare per ogni singolo file. Trasferire i byte, insomma, è solo una parte del mestiere. Con un unico file da 100 GB certe operazioni avvengono praticamente una volta sola. Con 500.000 file da 200 KB vanno ripetute mezzo milione di volte, e a quel punto il numero stampato sulla confezione, quel “scrittura sequenziale 7.000 MB/s”, smette di raccontare la verità.

Cosa succede davvero dietro ogni singolo file

Quando Windows copia un file non prende un blocco di dati e lo sposta e basta. Deve trovarlo nella directory, aprirlo, controllarne gli attributi, raccogliere le informazioni per accedervi. Sulla destinazione deve verificare il percorso, creare un nuovo oggetto, assegnargli spazio, aggiornare le strutture interne, scrivere i dati, impostare attributi e timestamp e infine chiudere tutto. Su NTFS, il file system usato di norma sulle unità Windows, il cuore di questo meccanismo è la Master File Table. Ogni file ha almeno una voce nella MFT, con i metadati che lo descrivono: dimensioni, attributi, timestamp, autorizzazioni, posizione dei dati. Creare mezzo milione di file significa quindi generare e modificare una montagna di metadati, oltre a gestire nomi, directory di appartenenza e allocazione dello spazio. In certi casi si aggiungono permessi e ACL, informazioni sul proprietario, dati di auditing e Alternate Data Streams.

Anche assegnare lo spazio ha un costo. Il file system deve capire quali cluster sono liberi, occuparli e aggiornare le strutture che tengono traccia di tutto, come il file speciale $Bitmap. Con un file grande può lavorare su porzioni ampie e procedere in modo continuo. Con tanti file minuscoli, invece, creazione, allocazione e aggiornamento dei metadati si alternano di continuo a scritture piccolissime. Un carico di lavoro completamente diverso, più vicino a una raffica di operazioni separate che a un trasferimento sequenziale. Qui contano gli IOPS e soprattutto il tempo necessario a chiudere ogni operazione. Un NVMe resta lontanissimo da un disco meccanico, ma non può cancellare il lavoro del software.

Cache, antivirus e il fattore rete

Windows usa una cache per ridurre gli accessi diretti all’unità. Una lettura può essere servita dalla RAM, una scrittura può finire prima in cache e arrivare sul disco dopo, con il meccanismo di write back. È anche per questo che una copia parte a razzo e poi rallenta: quando i buffer si riempiono, si scende alla velocità reale sostenibile dallo storage. Poi c’è l’antivirus, che spesso viene dimenticato. Una protezione in tempo reale intercetta le operazioni sul file system e analizza i file mentre vengono letti, creati o modificati. Il costo della singola verifica è minimo, ma moltiplicato per centinaia di migliaia diventa pesante, soprattutto con archivi, eseguibili e script. Non a caso Microsoft offre per Defender un Performance Analyzer che segnala file, estensioni, percorsi e processi con maggiore impatto sulle scansioni.

Su un NAS o un file server raggiunto via condivisioni SMB il divario esplode. Un file grande tiene la rete occupata quasi in continuazione e può avvicinarsi al limite fisico di 1, 2,5 o 10 Gbps. Tanti file piccoli aggiungono invece la latenza del protocollo: richieste inviate, tradotte dal server, completate, risposte rispedite indietro, chiusura, e si ricomincia. Microsoft stessa segnala che la creazione di un file è un’operazione costosa e che, con milioni di elementi, si può passare più tempo a creare oggetti che a spostare dati.

Robocopy, il multithreading e il Task Manager

La contromisura più efficace su Windows è Robocopy, lo strumento da riga di comando pensato per copie affidabili anche molto complesse. Offre controlli su nuovi tentativi, esclusioni, sincronizzazione e soprattutto la copia multithread, con una sintassi semplice del tipo robocopy sorgente destinazione /E /MT:16. Il multithreading non velocizza la creazione del singolo file, sovrappone le attese: mentre un thread aspetta, un altro trasferisce dati. Il valore predefinito è 8 thread, il massimo accettato è 128, ma esagerare può saturare CPU, storage o server e peggiorare le cose. Esiste anche l’opzione /J per l’I/O non bufferizzato, consigliata però per i file grandi.

Perfino stampare a video il nome di ogni file ha un peso, tanto che nei trasferimenti SMB conviene reindirizzare l’output con /LOG. E quando tutto sembra lento, il Task Manager, richiamabile con CTRL+MAIUSC+ESC, può mostrare nella sezione Prestazioni un’unità con tempo di attività vicino al 100% mentre trasferisce solo pochi MB al secondo.

Condividi:
39 Condivisioni