XFS kontra EXT4 på NVMe-servrar: Prestandatester och jämförelse i praktiken

Jag jämför XFS EXT4 på NVMe-servrar utifrån aktuella prestandatester och praktiska värden, och visar när vilket filsystem som har ett mätbart försprång. Jag fokuserar då på genomströmning, latens och verkliga arbetsbelastningar, så att du kan utnyttja NVMe-prestandan i servern på ett målinriktat sätt.

Centrala punkter

Till att börja med ska jag kort sammanfatta de viktigaste slutsatserna innan jag går in på detaljer, prestandatester och optimering.

• Slumpmässig I/O: Båda ligger mycket nära varandra; EXT4 har något högre genomströmning, medan XFS har jämnare latenser.
• Sekventiellt: XFS ligger ofta i täten när det gäller stora filer, medan EXT4 ligger strax efter med stabila hastigheter.
• Metadata: EXT4 har vissa små fördelar, XFS har konstanta svarstider.
• Applikationer: Det är jämnt i databaserna, med skillnader på endast några procent.
• Tuning: Kärnan, schemaläggaren, I/O-djupet, ledigt utrymme och monteringsalternativ gör skillnaden.

XFS och EXT4 på NVMe: teknisk översikt

EXT4 anses vara en beprövad Linux-standard och ger på NVMe en mycket pålitlig Det utgör grunden och fungerar som referens i många jämförelser. XFS hanterar stora filer, hög parallellitet och sekventiella dataströmmar och kan utnyttja NVMe-genomströmningen mycket väl. På modern hårdvara minskar skillnaderna, eftersom båda filsystemen har mognat under många år och nya kärnversioner ytterligare optimerar NVMe-stacken. I vardagliga arbetsbelastningar är det ofta belastningsprofilerna som avgör: många små, slumpmässiga åtkomstförfrågningar ligger mycket tätt ihop, medan stora sekventiella överföringar tenderar att gynna XFS. Den som fattar beslut bör därför känna till sin I/O-profil och inte bara förlita sig på allmänna Rankningar titta.

Slumpmässig I/O på NVMe: små block, hög parallellitet

Vid 4K- och 8K-åtkomst levererar båda filsystemen IOPS på en mycket liknande Nivå, ofta inom några få procentenheter. EXT4 uppvisar i vissa mätningar något högre genomsnittsvärden vid slumpmässig skrivning, vilket kan märkas i OLTP-liknande scenarier. XFS utmärker sig däremot med jämnare latenser och mindre jitter över längre körningstider, vilket gynnar förutsägbara svarstider vid blandade belastningar. I produktiva miljöer döljs ofta dessa subtila skillnader av cacher, applikationslogik och nätverksvägar. Därmed hamnar andra inställningsparametrar som buffercache, WAL-strategi eller I/O-djup i förgrunden (källa: 1, 4, 7).

Sekventiella överföringar: effektiv hantering av stora filer

När det gäller MB-stora block och långa, sekventiella strömmar ligger XFS ofta i täten, eftersom utsträckningslayouten hanterar stora filer effektivt förvaltas. Säkerhetskopieringsfönster, arkiveringsjobb och sekventiella kontrollpunkter gynnas märkbart av detta, särskilt på PCIe 4.0/5.0 NVMe. EXT4 ligger inte långt efter och levererar mycket bra hastigheter som i många konfigurationer knappt utgör någon begränsning. Ju längre strömmen är och ju större filen är, desto tydligare lutar fördelen åt XFS. En kompletterande översikt ger min korta Jämförelse av prestanda med typiska serverarbetsbelastningar (källa: 4, 5, 9).

Metadatabehandling: många små filer

Arbetsbelastningar med många filoperationer ställer höga krav på metadatabanorna och medför skillnader i låsning och journalföring Ljus. EXT4 ligger i vissa tester knappt i täten när det gäller snabb skapande och radering av många små filer. XFS håller dock jämna steg tack vare konstanta latenser och är därför lätt att planera för loggar, cacher och byggkataloger. Jämfört med alternativa filsystem uppvisar båda en välutvecklad hantering och förutsägbara reaktionsmönster. Den som hanterar stora mängder små filer bör beakta monteringsalternativen och köra praktiska tester under längre tidsperioder (källa: 1, 7, 13).

Översikt över jämförelsetal

Jag sammanfattar följande tendenser kortfattat så att du snabbt kan upptäcka typiska mönster känna igen. Slumpmässig I/O med små block: Skillnaderna är oftast små, ofta inom intervallet ±3–5 % för IOPS. Sekventiell I/O med stora block: XFS ligger ofta i täten, särskilt vid långa strömmar och stora filer. Metadatatunga tester: ibland en liten fördel för EXT4, XFS med jämna latenser. I analytiska scenarier utnyttjar båda filsystemen ofta cirka 80–85 % av den teoretiska NVMe-prestandan, beroende på kärna, drivrutiner och kontrollerfirmware (källa: 1, 3, 4, 5, 10).

Scenario	Tendens	Typisk fördel	Ledtråd
Slumpmässig I/O (4K/8K)	Mycket tätt	EXT4 har något högre genomströmning	XFS ger ofta jämnare latenser
Sekventiellt (≥1 MB)	XFS i täten	Högre genomströmning för stora filer	Långa strömmar förstärker effekten
Metadatamanipulationer	Nack och nack	EXT4 är delvis snabbare vid skapande och radering	XFS är stabilt vid blandad belastning
Databaser (OLTP)	Mycket tätt	EXT4 ger något högre TPS	XFS ger jämnare svarstider
Analys/rapportering	Eng	XFS vid omfattande skanningar	Båda använder 80–85 % av hårdvaran

Applikationsnära prestandatester: databaser och blandad belastning

I tester av PostgreSQL och MySQL ser jag en jämn kamp som präglas av latensprofiler, WAL-strategier och inställningar för buffertcachen lever. EXT4 ger ibland något fler transaktioner per sekund vid hög parallellitet. XFS utmärker sig med stabila svarstider, vilket kan jämna ut svansfördröjningar i kritiska API:er. Skillnaderna är så små att databasoptimering ger bättre resultat än att enbart byta filsystem. Den som ska fatta beslutet bör därför mäta typiska långvariga körningar för arbetsbelastningen och noggrant övervaka applikationsmått (källa: 2, 3, 9).

Kärnversion, NVMe-modeller och deras inverkan

Nyare Linux-kärnor i 5.x- och 6.x-serierna minskar latensen och ökar genomströmningen, vilket gynnar båda filsystemen på snabba NVMe-enheter och eliminerar flaskhalsar i I/O-stacken minskar. SSD-enheter för företag med stor DRAM-cache och strömavbrottsskydd döljer dessutom skillnaderna, eftersom kontrollern och firmware sätter gränser innan filsystemet börjar spela någon roll. Prisvärda NVMe-enheter för konsumenter visar skillnaderna tydligare, men ligger oftast nära varandra i vardagsanvändningen. PCIe 4.0/5.0 ökar utrymmet, vilket gör att de sekventiella fördelarna med XFS blir tydligare. Kerneluppdateringar, NVMe-firmware och rena drivrutinsversioner ger därför mätbara fördelar (källa: 1, 5, 10, 11).

Optimering för NVMe: schemaläggare, I/O-djup, ledigt utrymme

Jag börjar ofta med ett enkelt schemaläggningsprogram som ingen eller mq-deadline och anpassar I/O-djupet efter varje arbetsbelastning för att fylla köerna på ett effektivt sätt. Ett för högt djup orsakar latensspikar, medan ett för lågt djup slösar bort parallella resurser. Att planera in 15–20 % ledigt utrymme minskar fragmenteringen och håller allokeringarna snabba. För XFS tittar jag på fördelningen i allokeringsgrupper, eftersom de i hög grad påverkar filsystemets parallellitet; ett bra ämne att börja med är XFS-allokeringsgrupper. Jag utvärderar varje ändring genom en A/B-jämförelse, så att effekterna förblir spårbara och inga försämringar går obemärkt förbi.

Använda monteringsalternativen på ett målinriktat sätt

Mount-alternativen påverkar journalföring, bekräftelseintervall och skrivvägar och kan påverka latens och genomströmning märkbar flytta. EXT4 erbjuder användbara inställningsmöjligheter för journal-läge och commit-tider, medan XFS har alternativ för loggbuffertar och inode-parametrar. Jag anpassar dessa inställningar efter belastningsprofilen och dokumenterar varje ändring. Den som vill fördjupa sig ytterligare hittar kortfattade tips om användbara parametrar i EXT4-monteringsalternativ. Det är fortfarande viktigt att testa varje justering av monteringen med verkliga arbetsbelastningar, inte bara med syntetiska tester.

Praktisk webbhotellhantering: Val utifrån arbetsbelastning

För klassiska webbapplikationer med CMS och webbutiker erbjuder EXT4 en pålitlig Bas, eftersom många små filer och blandade I/O-mönster dominerar. Databaser med hög parallellitet fungerar mycket bra på båda filsystemen; jag fattar beslut utifrån befintliga erfarenheter, övervakningskonfigurationen och säkerhetskopieringsstrategin. Stora sekventiella dataströmmar vid säkerhetskopiering och arkivering gynnar XFS, vilket effektiviserar överföringsfönstren. Analysarbetsbelastningar drar också nytta av XFS:s hantering av stora skanningar, medan blandade profiler ofta visar knappt några skillnader. Den som är osäker kan sätta upp ett staging-system och mäta utifrån de viktigaste dagliga belastningarna.

Teststrategi: realistisk och mätbar

Jag kombinerar korta topptest med långa uthållighetslöpningar för att kunna mäta både maximala värden och jitter samt åldringseffekter se. Istället för enbart syntetiska verktyg använder jag kopior av produktiva databaser, typiska loggfiler och verkliga import-/exportjobb. Övervakning med iostat, perf och applikationsmetriker pågår alltid, så att jag entydigt kan påvisa korrelationer. Jag upprepar testerna efter kärnuppdateringar eller firmwarebyten för att tidigt upptäcka regressioner. På så sätt framgår det om XFS eller EXT4 i den egna miljön ger den bästa avvägningen mellan genomströmning, latens och förutsägbarhet (källa: 1).

Journalföring, barriärer och synkroniseringssemantik på NVMe

Journalföringsdetaljerna påverkar bland annat latensspikar och återställningsbeteendet. EXT4 använder som standard data=ordnad och skriver metadata till loggen, medan använddata sparas innan commit. Den som behöver maximal skrivhastighet med en acceptabel risk kan data=återskrivning överväga, vilket dock försvårar återuppspelningar efter krascher. Nyare versioner av EXT4 stöder fast_commit, vilket sammanför många små metadatatransaktioner och förkortar bekräftelsetiderna. XFS för en egen logg (journal), vars logbstorlek och loggbuffar påverkar parallelliteten och latensen avsevärt. På NVMe är Skrivspärrar Viktigt: Utan strömavbrottsskydd (Power-Loss-Protection, PLP) bör barriärerna förbli aktiva för att säkerställa omordningen av styrenhetens firmware. Med PLP kan man på ett målinriktat sätt minska antalet barriärer för att påskynda fsync()-krävande arbetsbelastningar – man måste dock alltid väga detta mot risken. För applikationer med strikta krav på datahållbarhet (t.ex. databaser) är ett korrekt fsync()-beteende viktigare än några procentenheter högre genomströmning.

TRIM/Discard och NVMe:s långsiktiga prestanda

Påverka i Flash Kassera/Trimma-Strategier för hållbar skrivprestanda. Inline-Discard vid mount (discard/async_discard) minskar kontrollerns bakgrundsarbete, men kan orsaka latensspikar under hög belastning. Periodisk fstrim-Körningar (t.ex. varje vecka) håller prestandan mer stabil i många produktionsmiljöer och separerar frigörandet av outnyttjade block från hot-path. XFS hanterar discard-operationer effektivt i batcher, medan EXT4 erbjuder discard=async en mjuk variant. Det är viktigt att ”Discard” sprids korrekt genom alla lager (dm-crypt, LVM, MD-RAID, hypervisor). Om man på lång sikt håller 15–20 % i reserv minskar den interna skräpinsamlingen – latensvariationerna minskar och skrivprestandan förblir stabilare.

RAID, LVM och kryptering: Att samordna lagren på rätt sätt

Innan formateringen bör blockgeometrin vara anpassad till RAID/LVM. För XFS avgörs det rätta valet av sunit/swidth (Allocation-Alignment) effektiviteten hos stora sekventiella överföringar; i EXT4 sköts detta av stride/stripe-width. Om justeringen är korrekt minimeras läs-modifiera-skriv-cyklerna i RAID. LVM-Thin och snapshots är praktiska, men ökar latensen i skrivvägarna – detta påverkar slumpmässiga arbetsbelastningar mer än rena skanningar. dm-kryptering/LUKS belastar processorn och kan begränsa IOPS vid små block; moderna AES-NI/ARM-Crypto hjälper till, men latensen i slutet av sekvensen ökar vanligtvis något. För krypterade volymer lönar det sig att justera I/O-djupet och köaffiniteten samt att uttryckligen tillåta Discard, om säkerhetsriktlinjerna tillåter detta.

CPU/NUMA, avbrottsaffinitet och io_uring: finjustering av latens

NVMe skalar över flera inlämnings-/avslutningsköer; den som NUMA-plats Observera att detta minskar antalet hop mellan noder. NVMe-IRQ:er och applikationens arbetstrådar bör köras på samma NUMA-nod som minnet är allokerat på. I Linux kan man använda IRQ-pinning och anpassade rps/xps-Inställningar för att behålla datavägen lokalt. Moderna arbetsbelastningar drar nytta av io_uring (i stället för den äldre AIO-versionen), som minskar antalet systemanrop och möjliggör batch-inlämning. I fio-tester visar sig detta i form av lägre latenser vid samma IOPS. För stora ködjup (iodepth) förvränger dock latensfördelningen; det är därför lämpligt att genomföra stegvisa tester (t.ex. 1, 4, 16, 64) för att identifiera den optimala punkten för varje arbetsbelastning.

Container- och VM-miljöer: Särdrag i stacken

När det gäller containrar (overlayfs) var XFS länge det vanligaste valet, eftersom d_type var tillgängligt tidigt och pålitligt, och stora lagersatser hanterades effektivt. Idag erbjuder moderna EXT4-installationer motsvarande stabilitet; prestandaskillnaderna är små och beror mer på overlayfs än på filsystemet. I virtuella maskiner dominerar hypervisorens Virtio-/NVMe-frontends och cachelägen: cache=none plus O_DIRECT i gästmodulen minskar dubbelbuffring. Viktigt är Discard-överlämning och enhetliga sektorstorlekar (4K jämfört med 512e) för att undvika skrivförstärkning. Snapshot-baserade plattformar (t.ex. QCOW2, ZVOL) inför Copy-on-Write; valet av filsystem i gästsystemet förblir relevant, men värdbackend begränsar ofta kapaciteten tidigare än XFS/EXT4 själva.

Återställning, konsistens och underhållsfönster

Båda filsystemen anses vara robusta, men Underhållsvägar skiljer sig åt. EXT4 kan kontrolleras noggrant med e2fsck; på mycket stora volymer tar det märkbart lång tid om det finns fel, men systemet drar nytta av stegvisa förbättringar (Fast-Commit förkortar återuppspelningen av mindre transaktioner). XFS är på Konsekvens online konfigurerad; djupgående kontroller körs med xfs_repair, vilket i nödfall kräver mycket RAM-minne och kan ta tid vid mycket stora trädstrukturer. För produktiva system lönar det sig att fsfreeze före LVM-/lagringssnapshots för att säkerställa applikationskonsistenta säkerhetskopior; databaser bör dessutom aktivera sina egna kontrollpunkts- och säkerhetskopieringsmekanismer. De som har SLA:er med korta RTO/RPO bör uttryckligen planera in återställningstester – detta avlivar myter och visar realistiska tidsfönster för driftstopp.

Funktionella aspekter utöver ren prestanda

Prestanda är inte allt. XFS erbjuder Reflink-baserade kopior och dedupliceringsfunktioner, vilket sparar lagringsutrymme och förkortar kopieringstiderna för VM-avbildningar och stora mediebestånd. EXT4 utmärker sig genom ett brett utbud av verktyg och konservativa standardinställningar som förenklar införandet. Kvoter finns tillgängliga i båda världarna; XFS utmärker sig med Projekt-Quotas för katalogbaserade kvoter i stora multitenant-strukturer. Alternativ som noatime/relatime/lazytime minskar belastningen vid skrivning av metadata märkbart. Den som använder kryptering per katalog eller per fil (fscrypt) bör räkna med en viss extra belastning vid små slumpmässiga åtkomstförfrågningar och se till att ha CPU-reserver tillgängliga.

Undvika mätfel: typiska fallgropar

Många av de påstådda skillnaderna mellan FS är i själva verket Testartefakter. För små datamängder hamnar i sidcachen och döljer skillnader; datamängderna bör vara större än det tillgängliga RAM-minnet. En saknad uppvärmning förvränger slumpmässiga skrivprofiler på flashminnet; även underhållsuppgifter som körs parallellt (scrubs, rebuilds, fstrim) leder till avvikelser. Vid fio-tester måste det vara klart om direct=1 man undersöker om fsync()-faserna är realistiskt inställda och om läs-/skrivkombinationer körs interleaved eller i faser. För att få reproducerbara resultat krävs fasta CPU-frekvenser (inga aggressiva skalningsregulatorer), konstant bakgrundsbelastning och tydlig isolering mellan test och övervakning.

Checklista för praktiken: så här gör du

• Klargöra arbetsbelastningsprofilen: Blockstorlekar, läs-/skrivförhållande, latensbudget, burstbeteende.
• Rensa stacken: Kärna, NVMe-firmware, drivrutinsversioner; kontrollera IRQ-affinitet och NUMA.
• Justera layouten: Ställ in RAID-/LVM-justeringen (sunit/swidth respektive stride/stripe-width) korrekt.
• Testa monteringsalternativ: Barriärer, commit-intervall, noatime/relatime/lazytime; XFS-loggparametrar.
• Kalibrera I/O-djupet: Avväga latens mot genomströmning, hitta den optimala balansen för varje applikation.
• Planera in ledigt utrymme: 15–20 % Reserv för jämna latenser och mindre fragmentering.
• Definiera en discard-strategi: Inline-fstrim jämfört med periodiskt fstrim, som sprids genom alla lager.
• Säkerhetskopiering och återställning: Testa fsfreeze-/Snapshot-processer, verifiera driftstopp på ett realistiskt sätt.
• A/B-mätningar: Ändra endast en variabel och korrelera resultaten med applikationsmätvärden.

Sammanfattning: Beslutsstöd utan myter

XFS och EXT4 ger mycket hög prestanda på NVMe, men skillnaderna är oftast måttlig och beror i hög grad på I/O-profilen. Slumpmässiga belastningar med små block ligger nära varandra, medan långa sekventiella strömmar tenderar att ge XFS ett försprång. EXT4 imponerar med något högre genomströmning i vissa transaktionsmönster, medan XFS utmärker sig med konstanta latenser under långvariga tester. Kärnversion, NVMe-modeller, schemaläggare, I/O-djup, ledigt utrymme och monteringsalternativ påverkar ofta resultatet i högre grad än valet av filsystem i sig. Den som mäter noggrant och förstår sina egna arbetsbelastningar kan fatta ett välgrundat beslut – utan myter och med mätbara Vinst.