Compressione NTFS su SSD - su e giù

In questo argomento viene illustrata la compressione NTFS su HDD come metodo per migliorare le prestazioni di accesso al disco e si conclude che è scadente il più delle volte. Ma ho sempre visto la compressione come un modo per conservare lo spazio e ne ho imparato l'efficacia. E ora ho un SSD in cui lo spazio è costoso e la penalità per le prestazioni, ad esempio per leggere / scrivere 2 cluster invece di 1, è molto più bassa.

D'altra parte, poiché gli SSD sono molto più veloci degli HDD, mi aspetto che un throughput più elevato comporti un utilizzo maggiore della CPU. Questo può diventare un problema? Qualche altro pensiero in merito?

Mi piace l'effetto salvaspazio, non è enorme ma è lì. Se la performance è una preoccupazione, preferirei disattivarla:

Microsoft l'ha scritto poco fa in un blog :

NTFS comprime i file dividendo il flusso di dati in CU (è simile a come funzionano i file sparsi). Quando i contenuti del flusso vengono creati o modificati, ogni CU nel flusso di dati viene compressa singolarmente. Se la compressione determina una riduzione di uno o più cluster, l'unità compressa verrà scritta sul disco nel suo formato compresso. Quindi un intervallo di VCN sparso viene attaccato alla fine dell'intervallo di VCN compresso per scopi di allineamento (come mostrato nell'esempio seguente). Se i dati non vengono compressi abbastanza per ridurre le dimensioni di un cluster, l'intera CU viene scritta sul disco nella sua forma non compressa.

Questo design rende l'accesso casuale molto veloce poiché è necessario decomprimere solo una CU per accedere a un singolo VCN nel file. Sfortunatamente, l'accesso sequenziale di grandi dimensioni sarà relativamente più lento poiché è necessaria la decompressione di molte CU per eseguire operazioni sequenziali (come i backup).

E in un articolo KB scrive questo :

Mentre la compressione del file system NTFS può risparmiare spazio su disco, la compressione dei dati può influire negativamente sulle prestazioni. La compressione NTFS presenta le seguenti caratteristiche prestazionali. Quando si copia o si sposta un file NTFS compresso in una cartella diversa, NTFS decomprime il file, copia o sposta il file nella nuova posizione, quindi ricomprime il file. Questo comportamento si verifica anche quando il file viene copiato o spostato tra le cartelle sullo stesso computer. Anche i file compressi vengono espansi prima della copia sulla rete, quindi la compressione NTFS non risparmia la larghezza di banda della rete.

Poiché la compressione NTFS è ad alta intensità di processore, il costo delle prestazioni è più evidente sui server, che sono spesso associati al processore. I server pesantemente caricati con molto traffico di scrittura sono candidati scarsi per la compressione dei dati. Tuttavia, è possibile che non si verifichi un significativo peggioramento delle prestazioni con server di sola lettura, prevalentemente di lettura o leggermente caricati.

Se si esegue un programma che utilizza la registrazione delle transazioni e che scrive costantemente in un database o registro, configurare il programma per archiviare i suoi file su un volume non compresso. Se un programma modifica i dati attraverso sezioni mappate in un file compresso, il programma può produrre pagine "sporche" più velocemente di quanto il writer mappato possa scriverle. Programmi come Accodamento messaggi Microsoft (noto anche come MSMQ) non funzionano con la compressione NTFS a causa di questo problema.

Poiché le cartelle home dell'utente e i profili di roaming utilizzano molte operazioni di lettura e scrittura, Microsoft consiglia di collocare le cartelle home dell'utente e i profili di roaming su un volume che non ha compressione NTFS nella cartella principale o nella radice del volume.

Sommario:

comprime solo piccoli file che non cambiano mai (legge solo e non scrive) perché le letture sono veloci, ma le scritture richiedono decompressione e una nuova compressione che richiede potenza della CPU e il tipo di archiviazione non è così importante.

Mentre Claudio dice molte cose in dettaglio, sto per riprendere la sua opinione che è anche mia, ho visto gli stessi effetti dopo aver provato quello che dice.

Per SSD la compressione NTFS non deve essere utilizzata.

Ora elencherò alcuni motivi per tale affermazione:

Motivo Nº1: ucciderà il musch SSD più velocemente, poiché fa due scritture; La compressione NTFS scrive sempre i dati non compressi prima di avviare la compressione su RAM e quindi riscrivere i dati compressi solo se si tratta di un guadagno di almeno 4KiB.

Motivo Nº2: l'utilizzo del cluster NTFS 4KiB su un SSD sta perdendo il 50% della velocità dell'SSD, controlla qualsiasi benchmark e vedrà i blocchi da 128 KiB rendere l'SSD due volte più veloce rispetto all'utilizzo dei blocchi 4KiB e la compressione NTFS può essere utilizzata solo su partizioni NTFS del cluster 4KiB.

Motivo Nº3: Esistono contenitori (come PISMO File Mount) che possono creare un contenitore che è visto come compressione e / o crittografia al volo, tali connerers eseguono la compressione su RAM e non inviano dati non compressi sul disco prima di riscriverli in forma compressa, anche di più, PISMO ottiene un rapporto di compressione migliore rispetto a NTFS.

Ci sono molti più motivi, ma questi sono i più importanti.

Il punto otrer è SPEED, qualsiasi compressione viene eseguita sulla CPU, quindi se non si dispone di una CPU molto veloce (mono-thread viene utilizzato per tale su NTFS mentre multi-thread viene utilizzato su alcuni contenitori) vedrà la lettura / scrittura molto lenta quando compresso; peggio, puoi avere una cpu molto veloce, ma se è in uso per altre cose (come rendering, transcodifica, ecc.) non è rimasto alcun cpu per la compressione, quindi di nuovo otterrai prestazioni scadenti.

La compressione NTFS è utile solo per i dischi lenti tradizionali quando si ha CPU senza molto uso, ma richiede una buona deframmentazione dopo ogni scrittura (a livello di file), poiché ogni blocco da 64 KiB (compresso o meno) è scritto in una posizione multipla di 64 KiB; l'unico modo per comprimere tali frammenti è dopo che la compressione (o la scrittura su una cartella compressa) esegue una deframmentazione di tale file.

PD: Attenzione, stiamo parlando di Windows su hardware reale, non all'interno di macchine virtuali, l'importante è chi scrive sul supporto fisico, altri possono avere livelli di cache che possono mitigare gli effetti e anche migliorare molto le cose.

Nessuno parla del problema del sindaco su non SSD, è frammentazione.

Ogni blocco da 64 KiB è scritto dove sarebbe senza compressione, ma può essere compresso, quindi almeno è <= 60 KiB, quindi scrive meno di 64 KiB, il blocco del bit bit andrà dove vorrebbe se il precedente non lo fosse comprimere, quindi un sacco di lacune apèars.

Provalo con un file multi gigabyte di una macchina virtuale di qualsiasi sistema Windows (tendono a ridursi al 50%, ma con un enorme> 10000 frammenti).

E per gli SSD c'è qualcosa che non viene detto, come diavolo scrive? Voglio dire, se lo scrive non compresso e poi lo sovrascrive con la versione compressa (per ogni mega blocchi da 64 KiB), la vita dell'SSD è molto ridotta; ma se lo scrive direttamente in forma compressa, allora SSD live potrebbe essere più lungo o più corto .... più a lungo se scrivi quel 64 KiB solo in una volta, più corto, ma più corto se scrivi quel 64 KiB in 4KiB, perché scriverà tale 64 KiB (in forma compressa) tante volte 64/4 = 16 volte.

La penalità prestazionale è causata dal fatto che il tempo della CPU necessario per comprimere / decomprimere è maggiore del tempo guadagnato in quanto non è necessario scrivere blocchi 4KiB ... quindi con una CPU molto veloce e una compressione del disco molto lenta riduce il tempo di scrittura e lettura, ma se SSD è molto veloce e la CPU è abbastanza lenta, scriverà molto più lentamente.

Quando parlo di CPU veloce o lenta intendo in quel momento, la CPU può essere utilizzata da 'matematica' o altri processi, quindi pensa sempre su CPU gratuita, non su specifiche CPU su carta, lo stesso vale per disco / SSD, può essere utilizzato da più processi.

Supponi di avere 7Zip che scrive un file enorme da un altro disco con LZMA2, utilizzerà molta CPU, quindi se allo stesso tempo stai copiando un file compresso NTFS, non ha CPU libera, quindi andrà più lentamente che senza NTFS compressione, ma non appena 7Zip finisce di utilizzare la CPU, tale CPU sarà in grado di comprimere più velocemente NTFS, e in quel momento la compressione NTFS può fare le cose più velocemente.

Personalmente non utilizzo mai la compressione NTFS, preferisco i contenitori PFOMO con montaggio su file PISMO (con compressione, e consente anche l'iscrizione, sia al volo che trasparente per le app), offre un rapporto di compressione molto migliore e un minore impatto sulla CPU, mentre è una lettura e scrivere al volo, non è necessario decomprimerlo prima dell'uso, basta montarlo e utilizzarlo in modalità lettura e scrittura.

Dato che PISMO esegue la compressione su RAM prima di scrivere su disco, può prolungare la durata dell'SSD, i miei test di compressione NTFS mi fanno pensare che invii i dati sul disco due volte, prima non compresso, e successivamente se può comprimere viene sovrascritto in forma compressa .

Perché la velocità di scrittura compressa NTFS sul mio SSD è quasi 1/2 di quella non compressa con file rispetto alla compressione a circa 1/2 della sua dimensione o dimensioni compresse inferiori? Nel mio AMD Threadripper 2950 (32 core e 64 thread) con 128GiB di RAM (CPU veloce, CPU molto veloce) con meno dell'1% di utilizzo di esso, quindi c'è molta CPU per fare compressione più veloce della velocità secuential massima SSD, forse perché La compressione NTFS inizia dopo che i blocchi da 64 KiB vengono inviati al disco non compressi e quindi sovrascritti con la versione compressa ... oh se lo faccio su una macchina virtuale che esegue Linux su host e Windows su guest, la cache di Linux mi informa che tali cluster vengono scritti due volte e la velocità è molto, molto più veloce (Linux sta memorizzando nella cache le scritture NTFS non compresse inviate dal guest Windows e poiché dopo che vengono sovrascritte con dati compressi, Linux non invia dati non compressi sul disco,

La mia raccomandazione, non usare la compressione NTFS, tranne che nei guest di macchine virtuali che eseguono windows se l'host è Linux, e mai e poi se si usa la CPU molto se la CPU non è abbastanza veloce.

Il moderno SSD ha una enorme ram cache interna, in modo che write + overwtite causato dalla compressione NTFS possa essere mitigato dal sistema di cache interna SSD.

I miei test sono stati eseguiti su SSD "graziosi" senza RAM interna per cache all'interno dell'SSD, quando li ripeto su quelli con ram cache, la velocità di scrittura è veloce, ma non come si potrebbe pensare.

Fai i tuoi test e usa file di dimensioni enormi (più grandi del totale tam installato per evitare risultati nascosti nella cache).

A proposito, qualcosa che alcune persone non conoscono la vompressione NTFS ... qualsiasi file di 4KiB o inferiore non otterrà mai la compressione NTFS perché non c'è modo di ridurne le dimensioni almeno di 4KiB.

La compressione NTFS prende un blocco di 64 KiB, li comprime e se può ridurre un cluster (4KiB), allora è scritto compresso, 64 KiB sono 16 blocchi di 4KiB (consecutivi).

Se un file di 8 KiB al termine della compressione il risultato finale è superiore a 4KiB, non salva alcun cluster, quindi è scritto non compresso, ... e così via ... la pressione deve guadagnare almeno 4KiB.

Ah, e per la compressione NTFS, NTFS deve avere una dimensione del cluster di 4KiB.

Prova e fai un test: usa un cluster da 128 KiB su un NTFS su SSD vedrai un enorme miglioramento delle velocità di scrittura e lettura.

I filesystem su SSD con cluster 4KiB stanno perdendo molta della loro velocità, nella maggior parte dei casi perdono oltre il 50% ... vedi tutti i benchmark là fuori che testano con blocchi di dimensioni diverse, da 512Bytes a 2MiB, la maggior parte di SSD scrive al doppio velocità su una dimensione del cluster di 64 KiB (o 128 KiB) rispetto a 4KiB.

Vuoi un vero impegno sul tuo SSD? Non utilizzare il cluster 4KiB sul filesystem, utilizzare 128 KiB.

Utilizzare il cluster 4KiB solo se oltre il 99% dei file è inferiore a 128 KiB.

Ecc, ecc, ecc ... testare, testare e testare il proprio caso.

Nota: creare la partizione NTFS di sistema con diskpart in modalità console durante l'installazione di Windows con cluster 128KiB o da un'altra Windows, ma non consentire la formattazione di Windows nella parte grafica del programma di installazione (lo formatterà sempre come cluster NTFS 4KiB).

Tutti i miei Windows sono ora installati sulla partizione NTFS del cluster da 128 KiB su SSD (SLC) da 400GiB.

Spero che le cose diventino chiare, M $ non sta dicendo come scrivo NTFS compresso, i miei test mi dicono che scrive due volte (64 KiB non compresso, quindi <= 60 KiB concordato), non solo una volta (attenzione a questo se su SSD).

Attenzione: Windows tenta di comprimere alcune directory interne NTFS, indipendentemente dal fatto che non si comprenda alcuna compressione NTFS, l'unico modo per evitarlo davvero se la dimensione del cluster NFTS è diversa da 4KiB, poiché la compressione NTFS funziona solo su partizioni NTFS di dimensioni cluster 4KiB

Vedo i commenti di altri e penso che la gente dimentichi spesso lo scenario più utile in cui la compressione di file / cartelle NTFS ha un grande vantaggio su SSD: i moderni strumenti di sviluppo. Il mio Matlab con licenza universitaria ha nella sua cartella di installazione (per utenti comuni di sola lettura) le seguenti quantità di dati:

28,5 GB di dati 30,6 GB Dimensioni su disco Contiene 729.246 file e 15.000 cartelle (!!!)

Questo è sul mio laptop con SSD da 500 GB, dove la partizione di Windows è di 200 GB.

So che Matlab è un po 'estremo in questo senso, ma molti sviluppatori hanno proprietà simili: una tonnellata di piccoli file di testo altamente comprimibili (intestazioni, codice, file XML). Sto comprimendo Matlab ora prima di installare Intel Quartus FPGA devtool e Octave è già compresso come segue:

1,55 GB Dimensione dati su disco: 839 GB Contiene 34.362 file 1.955 cartelle

Questo materiale è stato scritto una volta e letto miliardi di volte durante le build del progetto. Ha perfettamente senso consumare un po 'di energia della CPU per decomprimerlo e risparmiare forse metà del tuo prezioso spazio SSD.

È necessario eseguire il benchmark due volte per sapere. Compressa. Non compresso. Dimentica l'usura degli SSD. Sono necessari un ssd e una CPU veloci, quindi non si verificano colli di bottiglia.

Un SSD da 512 GB costa 50 dollari in questi giorni. Finora per me l'accesso al disco più veloce è usare Linux ove possibile e il meccanismo di coda del disco LIFO. Piuttosto che CFQ.

Windows 10 crea infinite attività del disco con ram da 12 GB installato sul mio laptop. Dopo il caricamento si verifica il conteggio di Linux e quasi zero l'accesso al disco. A meno che tu non lo avvii. Windows ha solo un modo per tenersi occupato senza compiti visibili.