Hur påverkar filsystemskomprimering skrivprestandan på hemmets NAS?

Filsystemskomprimering kan göra en hemma-NAS snabbare när den tar bort mer lagringsarbete än den lägger till CPU-arbete, men den kan också öka latensen.

Resultatet beror på vad NAS:en lagrar, vilken komprimeringsalgoritm och nivå den använder, och om den aktiva flaskhalsen är processorn, diskpoolen eller den synkrona skrivvägen. Denna artikel fokuserar på transparent filsystemskomprimering – inte ZIP-arkiv eller SMB-komprimering – eftersom varje fungerar i olika steg av datapathen.

Den grundläggande avvägningen: färre skrivna byte, mer CPU-arbete

Transparent komprimering sitter inuti filsystemets skrivväg. Applikationer skickar logisk data, filsystemet delar upp datan i poster eller extent, och komprimeringsmotorn försöker koda varje enhet i färre byte innan tilldelning. När den lyckas når färre block lagringspoolen. En detaljerad förklaring av transparent filsystemskomprimering visar varför poststorlek, komprimeringsgrad och fysisk blockstorlek alla påverkar hur mycket I/O som faktiskt sparas.

Detta skapar en utväxling snarare än en universell hastighetsökning. CPU:n spenderar tid på att hitta upprepade mönster, men diskarna, SSD:erna, paritetslagret och lagringsbussen hanterar en mindre fysisk last. Om den sparade enhetstiden är större än komprimeringstiden ökar den applikationssynliga skrivgenomströmningen. Om CPU:n redan var upptagen eller datan knappt krymper kan det extra steget öka skrivlatensen utan att ta bort tillräckligt med I/O för att kompensera.

Den rapporterade hastigheten kan också missförstås. Ett kopieringsverktyg mäter logiska byte som tas emot från klienten, medan diskstatistik visar fysiska byte skrivna efter komprimering. En NAS kan därför rapportera 500 MB/s i logisk framsteg medan dess diskar tar emot mycket mindre än 500 MB/s. Filsystemskomprimering minskar inte automatiskt den inkommande SMB-trafiken; nätverkskomprimering måste agera tidigare i kedjan.

Komprimerbarhet avgör hur mycket lagringsarbete som försvinner

Komprimering tar bara bort arbete när ingången innehåller återanvändbara mönster. Text, loggar, källkod, upprepade databassfält och nollfyllda områden har ofta tillräcklig redundans för att krympa avsevärt. JPEG, HEVC-video, ZIP-arkiv och krypterade filer har redan tagit bort eller dolt dessa mönster. Sambandet mellan dataredundans och komprimering förklarar varför två NAS-mappar med lika storlek kan ge motsatta skrivprestandaresultat.

En hem-NAS har sällan en enhetlig arbetsbelastning, så den användbara frågan är inte om komprimering är snabb i isolering. Det är om den aktiva datamängden blir tillräckligt liten för att minska den långsammaste delen av sin egen skrivväg.

Ordningen spelar också roll. Data som komprimeras före kryptering kan fortfarande spara utrymme, men chiffertext ser normalt ut som hög entropi för ett senare filsystemlager. På samma sätt kan en gles eller delvis tom VM-bild komprimeras väl även om operativsystemet inuti lagrar blandat innehåll. Filändelser är användbara ledtrådar, inte pålitliga mått på de block som filsystemet ser.

Algoritm och komprimeringsnivå bestämmer CPU–I/O-utbyteshastigheten

Snabba algoritmer föredrar låg bearbetningstid och måttlig storleksreduktion, medan tyngre algoritmer spenderar mer CPU-tid på att söka efter en bättre kvot. Detta är samma gräns mellan hastighet och storlek som syns i oberoende jämförelser av komprimeringsmetoder. För en NAS som alltid är på är den bästa kvoten inte automatiskt den bästa skrivprestandan eftersom varje förgrunds- och bakgrundsskrivare delar samma processor.

Komprimeringsnivå gör den gränsen mer detaljerad. Publicerade Zstandard-nivåmätningar visar att komprimeringshastigheten sjunker när den begärda förhållandet ökar, medan dekomprimering förblir relativt snabb. Det gör en hög nivå attraktiv för arkivskrivningar på inaktiv hårdvara men potentiellt störande för live-databaser, containerloggar eller flera klienter som skriver samtidigt.

Ingen algoritmetikett ger ett universellt resultat. Processor-generation, tillgängliga kärnor, minnesbandbredd, implementation, bitstorlek och dataset spelar alla roll. En snabb algoritm på en lågströms-CPU kan fortfarande vara flaskhalsen bakom en snabb NVMe-pool, medan en starkare algoritm kan förbli i praktiken gratis när långsamma diskar dominerar samma NAS.

Enhetens media och skrivmönster flyttar flaskhalsen

Roterande diskar ger vanligtvis större möjlighet för komprimering att hjälpa eftersom varje borttagen block undviker relativt dyr enhetsarbete. En NVMe-pool kan absorbera mycket mer data innan lagringen blir begränsningen, så komprimerings-CPU-tid är lättare att exponera. Den bredare principen är att CPU-arbete kan ersätta lagrings-I/O, men vilken resurs som är bäst att använda beror på den faktiska hårdvarubalansen.

Skrivform påverkar också svaret. Stora asynkrona strömmar ger filsystemet utrymme att batcha och parallellisera arbetet. Små synkrona uppdateringar väntar fortfarande på hållbarhetsbekräftelser, så minskad payload-storlek tar kanske inte bort den fasta latensen vid en flush eller journal-commit. Filsystemimplementeringar komprimerar också i specifika enheter: nuvarande Btrfs komprimeringsbeteende använder till exempel begränsade bitar, parallell bearbetning och implementeringsspecifika regler som kan ändra metadataanvändning och skrivlatens.

Samtidighet lägger till en annan gräns. Flera säkerhetskopior, appdatabaser, medieimporter och container-skrivare kan tillsammans mätta CPU:n även när varje ström drar nytta av det ensam. Komprimering bör därför tolkas tillsammans med flaskhalsar i nätverk, minne, enhet och bakgrundsuppgifter, särskilt när genomströmningen bara sjunker under schemalagda jobb eller vid aktivitet från flera användare.

Komprimeringsbenchmarks måste jämföra logiskt och fysiskt arbete

Ett benchmark fyllt med nollor eller upprepade bytes kan få ett komprimerat filsystem att verka snabbare än vad dess enheter någonsin kan skriva. Det resultatet kan vara matematiskt korrekt för den logiska arbetsbelastningen men värdelöst för ett fotoarkiv eller krypterad backup. Vanliga lagringsbenchmarkfel inkluderar mycket komprimerbar testdata, cachade läsningar, oskrivna skrivningar och att inte jämföra applikationsgenomströmning med enhetsaktivitet.

Ett meningsfullt test av hemmets NAS använder samma hårdvara, dataset, klientväg och bakgrundslast med komprimering aktiverad och inaktiverad. Det registrerar logisk genomströmning, fysiska enhetsbyte, CPU-användning, komprimeringsgrad och skrivlatens. För synkrona eller multi-klient arbetsbelastningar är percentil-latens mer informativt än ett enda toppvärde i MB/s eftersom korta stopp kan döljas i ett högt genomsnitt.

Den slutgiltiga tolkningen är villkorad. Om fysiska skrivningar sjunker kraftigt medan CPU:n förblir under mättnad, fungerar komprimering som en genomströmningsförstärkare. Om förhållandet ligger nära 1:1 och CPU eller latens ökar, är det mest extra arbete. Om nätverket redan är flaskhalsen kan lagringen bli mer effektiv utan att klientkopian blir klar snabbare.

Vanliga frågor

Saktar filsystemskomprimering alltid ner NAS-skrivningar?

Nej. Det kan öka den logiska skrivgenomströmningen när komprimerbar data och en lagringsflaskhals gör att sparad I/O överväger CPU-kostnaden. Det kan vara neutralt eller långsammare med högentropisk data, begränsad CPU-kapacitet, aggressiva komprimeringsnivåer eller latenskänsliga skrivningar.

Vilka filer på hemmets NAS gynnas mest av komprimering?

Loggar, text, källkod, upprepad strukturerad data och delvis tomma virtuella diskar är vanliga kandidater. Redan komprimerade medier, arkiv och krypterad data ger vanligtvis mindre nytta, även om det verkliga resultatet beror på blockinnehållet snarare än bara filnamnet.

Kan filsystemskomprimering minska SSD-slitage?

Det kan minska värddatans skrivningar till SSD:n när blocken komprimeras väl, vilket kan sänka en del av enhetens arbetsbelastning. Det eliminerar inte controller-nivåns skräpinsamling eller skrivförstärkning, så hållbarhetsvinster beror på filsystem, arbetsbelastning, ledigt utrymme och SSD-firmware.