Come influisce la compressione del filesystem sulle prestazioni di scrittura di un NAS domestico?

La compressione del filesystem può far scrivere più velocemente un NAS domestico quando rimuove più lavoro di archiviazione di quanto ne aggiunga alla CPU, ma può anche aumentare la latenza.

Il risultato dipende da cosa il NAS memorizza, quale algoritmo e livello di compressione utilizza, e se il collo di bottiglia attivo è il processore, il pool di dischi o il percorso di scrittura sincrona. Questo articolo si concentra sulla compressione trasparente del filesystem—non sugli archivi ZIP o sulla compressione SMB—perché ognuno agisce in una fase diversa del percorso dei dati.

Il compromesso principale: meno byte scritti, più lavoro della CPU

La compressione trasparente si trova all'interno del percorso di scrittura del filesystem. Le applicazioni inviano dati logici, il filesystem divide quei dati in record o estensioni, e il motore di compressione cerca di codificare ogni unità in meno byte prima dell'allocazione. Quando ci riesce, meno blocchi raggiungono il pool di archiviazione. Una spiegazione dettagliata di compresssione trasparente del filesystem mostra perché la dimensione del record, il rapporto di compressione e la dimensione fisica del blocco influenzano la quantità di I/O effettivamente risparmiata.

Questo crea uno scambio piuttosto che un aumento universale della velocità. La CPU impiega tempo a trovare schemi ripetuti, ma i dischi, gli SSD, il livello di parità e il bus di archiviazione gestiscono un carico fisico minore. Se il tempo risparmiato sul dispositivo è maggiore del tempo di compressione, la velocità di scrittura visibile all'applicazione aumenta. Se la CPU era già occupata o i dati si riducono appena, la fase aggiuntiva può aumentare la latenza di scrittura senza rimuovere abbastanza I/O per compensare.

La velocità riportata può anche essere fraintesa. Uno strumento di copia misura i byte logici accettati dal client, mentre le statistiche del disco mostrano i byte fisici scritti dopo la compressione. Un NAS può quindi segnalare 500 MB/s di progresso logico mentre i suoi dischi ricevono molto meno di 500 MB/s. La compressione del filesystem non riduce automaticamente il traffico SMB in ingresso; la compressione di rete dovrebbe agire prima nel percorso.

La comprimibilità determina quanto lavoro di archiviazione scompare

La compressione rimuove lavoro solo quando l'input contiene schemi riutilizzabili. Testi, log, codice sorgente, campi di database ripetuti e regioni riempite di zeri spesso hanno abbastanza ridondanza per ridursi sostanzialmente. JPEG, video HEVC, archivi ZIP e file crittografati hanno già rimosso o oscurato questi schemi. La relazione tra ridondanza dei dati e compressione spiega perché due cartelle NAS di uguale dimensione possono produrre risultati opposti nelle prestazioni di scrittura.

Un NAS domestico raramente gestisce un carico di lavoro uniforme, quindi la domanda utile non è se la compressione sia veloce in isolamento. È se il dataset attivo diventa abbastanza piccolo da ridurre la parte più lenta del proprio percorso di scrittura.

Anche l'ordine conta. I dati compressi prima della crittografia possono ancora risparmiare spazio, ma il testo cifrato normalmente appare ad alta entropia a un livello successivo del filesystem. Allo stesso modo, un'immagine VM sparsa o parzialmente vuota può comprimersi bene anche se il sistema operativo al suo interno memorizza contenuti misti. Le estensioni dei file sono indizi utili, non misurazioni affidabili dei blocchi che il filesystem vede.

Algoritmo e livello di compressione determinano il tasso di scambio CPU–I/O

Gli algoritmi veloci favoriscono un basso tempo di elaborazione e una riduzione moderata delle dimensioni, mentre gli algoritmi più pesanti impiegano più tempo CPU per cercare un rapporto migliore. Questo è lo stesso confine tra velocità e dimensione visibile nelle comparazioni indipendenti di metodi di compressione. Per un NAS sempre attivo, il miglior rapporto non è automaticamente la migliore prestazione di scrittura perché ogni scrittore in primo piano e in background condivide lo stesso processore.

Il livello di compressione rende quel limite più granulare. Le misurazioni pubblicate dei livelli Zstandard mostrano che la velocità di compressione diminuisce all’aumentare del rapporto richiesto, mentre la decompressione rimane comparativamente veloce. Questo rende un livello alto attraente per scritture di archiviazione su hardware inattivo ma potenzialmente dirompente per database live, log di container o più client che scrivono contemporaneamente.

Nessuna etichetta di algoritmo fornisce un risultato universale. Generazione del processore, core disponibili, larghezza di banda della memoria, implementazione, dimensione del chunk e dataset sono tutti fattori importanti. Un algoritmo veloce su una CPU a basso consumo può comunque essere il collo di bottiglia dietro un pool NVMe veloce, mentre un algoritmo più potente può rimanere praticamente gratuito quando dischi lenti dominano lo stesso NAS.

Il supporto di memorizzazione e il modello di scrittura spostano il collo di bottiglia

I dischi rotazionali offrono solitamente maggiori opportunità per la compressione perché ogni blocco rimosso evita un lavoro relativamente costoso del dispositivo. Un pool NVMe può assorbire molti più dati prima che lo storage diventi il limite, quindi il tempo CPU per la compressione è più facile da evidenziare. Il principio più ampio è che il lavoro della CPU può sostituire l’I/O di storage, ma la risorsa migliore da utilizzare dipende dall’effettivo bilanciamento hardware.

La modalità di scrittura cambia anche la risposta. Grandi flussi asincroni danno al filesystem spazio per raggruppare e parallelizzare il lavoro. Aggiornamenti piccoli e sincroni attendono ancora le conferme di durabilità, quindi una riduzione della dimensione del payload potrebbe non eliminare la latenza fissa di un flush o di un commit del journal. Le implementazioni del filesystem comprimono anche a unità specifiche: il comportamento attuale della compressione Btrfs, per esempio, utilizza chunk limitati, elaborazione parallela e regole specifiche dell’implementazione che possono modificare l’uso dei metadati e la latenza di scrittura.

La concorrenza aggiunge un ulteriore limite. Più backup, database di app, importazioni di media e scrittori di container possono saturare collettivamente la CPU anche quando ogni flusso ne beneficia singolarmente. La compressione dovrebbe quindi essere interpretata insieme ai colli di bottiglia di rete, memoria, disco e attività in background, specialmente quando la velocità di trasferimento diminuisce solo durante lavori programmati o attività multi-utente.

I benchmark di compressione devono confrontare lavoro logico e fisico

Un benchmark pieno di zeri o byte ripetuti può far sembrare un filesystem compresso più veloce di quanto i suoi drive possano mai scrivere. Quel risultato può essere matematicamente corretto per il carico di lavoro logico ma inutile per un archivio fotografico o un backup criptato. Errori comuni nei benchmark di storage includono dati di test altamente comprimibili, letture in cache, scritture non svuotate e mancata comparazione del throughput applicativo con l'attività del dispositivo.

Un test significativo su un NAS domestico utilizza lo stesso hardware, dataset, percorso client e carico di fondo con la compressione abilitata e disabilitata. Registra il throughput logico, i byte fisici del dispositivo, l'utilizzo della CPU, il rapporto di compressione e la latenza di scrittura. Per carichi di lavoro sincroni o multi-client, la latenza percentilica è più informativa di un singolo valore di MB/s di picco perché brevi pause possono essere nascoste in una media elevata.

L'interpretazione finale è condizionale. Se le scritture fisiche diminuiscono drasticamente mentre la CPU rimane sotto saturazione, la compressione agisce come amplificatore di throughput. Se il rapporto resta vicino a 1:1 e la CPU o la latenza aumentano, è per lo più lavoro extra. Se la rete è già il limite, lo storage può diventare più efficiente senza far terminare prima la copia del client.

Domande Frequenti

La compressione del filesystem rallenta sempre le scritture NAS?

No. Può aumentare la velocità di scrittura logica quando i dati comprimibili e un collo di bottiglia di archiviazione fanno sì che l'I/O risparmiato superi il costo della CPU. Può essere neutro o più lento con dati ad alta entropia, CPU limitata, livelli di compressione aggressivi o scritture sensibili alla latenza.

Quali file NAS domestici traggono maggior beneficio dalla compressione?

Log, testo, codice sorgente, dati strutturati ripetuti e dischi virtuali parzialmente vuoti sono candidati comuni. Media già compressi, archivi e dati criptati di solito offrono meno vantaggi, anche se il risultato reale dipende dal contenuto dei blocchi e non solo dal nome del file.

La compressione del filesystem può ridurre l'usura dell'SSD?

Può ridurre i dati scritti dall'host sull'SSD quando i blocchi si comprimono bene, il che può abbassare parte del carico di lavoro del dispositivo. Non elimina la raccolta dei rifiuti a livello di controller né l'amplificazione della scrittura, quindi i guadagni in durata dipendono dal filesystem, dal carico di lavoro, dallo spazio libero e dal firmware dell'SSD.