Videre til indhold 
Jeg sammenligner XFS EXT4 på NVMe-servere ud fra aktuelle benchmarks og praktiske målinger og viser, hvornår hvilket filsystem har en målbar fordel. Her fokuserer jeg på gennemstrømning, latenstider og reelle arbejdsbelastninger, så du kan udnytte NVMe-ydeevnen på serveren målrettet.
Centrale punkter
Indledningsvis vil jeg kort opsummere de vigtigste konklusioner, inden jeg går i dybden med detaljer, benchmarks og optimering.
- Tilfældig I/O: Begge ligger meget tæt på hinanden; EXT4 har en anelse højere gennemstrømning, mens XFS har mere ensartede ventetider.
- Sekventielt: XFS ligger ofte i spidsen, når det gælder store filer, mens EXT4 ligger tæt bagved med solide hastigheder.
- Metadata: EXT4 har nogle små fordele, XFS har konstante responstider.
- Applikationer: I databaser ligger de side om side, med forskelle i det lave procentområde.
- Indstilling: Kernel, scheduler, I/O-dybde, ledig plads og monteringsindstillinger gør hele forskellen.
XFS og EXT4 på NVMe: teknisk oversigt
EXT4 betragtes som en velafprøvet Linux-standard og leverer på NVMe en meget pålidelig Det danner grundlag og fungerer som reference i mange sammenligninger. XFS er velegnet til store filer, høj parallelitet og sekventielle datastrømme og kan udnytte NVMe-gennemstrømningen meget effektivt. På moderne hardware mindskes forskellene, fordi begge filsystemer har modnet gennem årene, og nye kernelversioner optimerer NVMe-stakken yderligere. I dagligdags arbejdsbelastninger er det ofte belastningsprofilerne, der er afgørende: mange små, tilfældige adgangshændelser ligger meget tæt på hinanden, mens store sekventielle overførsler generelt favoriserer XFS. Den, der skal træffe beslutninger, bør derfor kende sin I/O-profil og ikke kun basere sig på generelle Ranglister se.
Random I/O på NVMe: små blokke, høj parallelitet
Ved 4K- og 8K-adgang leverer begge filsystemer IOPS på et meget lignende Niveau, ofte inden for få procentpoint. EXT4 viser i nogle målinger minimalt højere gennemsnitsværdier ved tilfældig skrivning, hvilket kan ses i OLTP-lignende scenarier. XFS udmærker sig derimod med mere ensartede ventetider og mindre jitter over længere kørselstider, hvilket fremmer forudsigelige svartider ved blandede belastninger. I produktive miljøer overskygges disse fine forskelle ofte af cacher, applikationslogik og netværksstier. Dermed kommer andre justeringsmuligheder som buffer-cache, WAL-strategi eller I/O-dybde i forgrunden (Kilde: 1, 4, 7).
Sekventielle overførsler: effektiv flytning af store filer
Når det drejer sig om MB-store blokke og lange, sekventielle strømme, ligger XFS ofte foran, fordi extent-layoutet håndterer store filer effektivt administreret. Backup-vinduer, arkiveringsopgaver og sekventielle checkpoints drager mærkbar fordel heraf, især på PCIe 4.0/5.0 NVMe. EXT4 ligger tæt på og leverer meget gode hastigheder, som i mange opsætninger næppe udgør en begrænsning. Jo længere strømmen er, og jo større filen er, desto tydeligere ligger fordelen hos XFS. Et supplerende overblik findes i min korte Sammenligning af ydeevne med typiske serverbelastninger (kilde: 4, 5, 9).
Metadata-operationer: mange små filer
Arbejdsbelastninger med mange filoperationer stiller store krav til metadatastierne og medfører forskelle i låsning og journalføring Lys. EXT4 ligger i nogle tests en smule foran, når der oprettes og slettes mange små filer hurtigt. XFS holder derimod stand med konstante ventetider og er derfor velegnet til logfiler, cacher og build-mapper. Sammenlignet med alternative filsystemer udviser begge en veludviklet administration og forudsigelige reaktionsmønstre. Den, der flytter store mængder små filer, bør være opmærksom på monteringsindstillingerne og køre praktiske tests over længere tidsperioder (kilde: 1, 7, 13).
Oversigt over benchmark-resultater i tal
Jeg opsummerer de følgende tendenser kortfattet, så du hurtigt kan få et overblik over de typiske mønstre genkende. Tilfældig I/O med små blokke: Forskellene er som regel små, ofte i området ±3–5 % for IOPS. Sekventiel I/O med store blokke: XFS ligger ofte foran, især ved lange strømme og store filer. Metadatatunge tests: til tider en lille fordel til EXT4, XFS med ensartede ventetider. I analytiske scenarier udnytter begge filsystemer ofte omkring 80–85 % af den teoretiske NVMe-ydeevne, afhængigt af kerne, driver og controller-firmware (kilde: 1, 3, 4, 5, 10).
| Scenarie | Tendens | Typisk fordel | Hint |
|---|---|---|---|
| Tilfældig I/O (4K/8K) | Meget tæt | EXT4 har en ansmægtig højere gennemstrømning | XFS har ofte lavere ventetider |
| Sekventielt (≥1 MB) | XFS i spidsen | Højere gennemstrømning ved store filer | Lange streams forstærker effekten |
| Metadata-operationer | Hals og hals | EXT4 er til tider hurtigere ved oprettelse/sletning | XFS er stabil ved blandet belastning |
| Databaser (OLTP) | Meget tæt | EXT4 giver en anelse højere TPS | XFS giver mere ensartede responstider |
| Analytik/rapportering | Eng | XFS ved store scanninger | Begge bruger 80–85 % af HW |
Anvendelsesorienterede benchmarks: Databaser og blandet belastning
I PostgreSQL- eller MySQL-tests ser jeg et tæt løb, der afhænger af latenstidsprofiler, WAL-strategier og buffer-cache-indstillinger lever. EXT4 leverer til tider en anelse flere transaktioner pr. sekund ved høj parallelitet. XFS udmærker sig ved stabile svartider, hvilket kan udjævne haleforsinkelser i kritiske API’er. Forskellene er så små, at optimering af databasen har større effekt end et rent skift af filsystem. Den, der skal træffe beslutningen, bør derfor måle typiske langvarige kørsler for den pågældende arbejdsbelastning og nøje overvåge applikationsmetrikkerne (kilde: 2, 3, 9).
Kernel-version, NVMe-modeller og deres indflydelse
Nyere Linux-kerner i 5.x- og 6.x-serierne reducerer ventetiderne og øger gennemstrømningen, hvilket kommer begge filsystemer til gode på hurtige NVMe-drev og fjerner flaskehalse i I/O-stakken mindsker. Enterprise-SSD’er med stor DRAM-cache og strømsvigtbeskyttelse udjævner forskellene yderligere, fordi controlleren og firmwaren sætter begrænsninger, før filsystemet kommer til at spille en rolle. Billige NVMe-drev til forbrugermarkedet viser forskellene tydeligere, men ligger som regel tæt på hinanden i dagligdagen. PCIe 4.0/5.0 øger headroom, hvilket gør de sekventielle fordele ved XFS mere synlige. Kernel-opdateringer, NVMe-firmware og opdaterede drivere giver derfor målbare fordele (kilde: 1, 5, 10, 11).
Optimering til NVMe: Scheduler, I/O-dybde, ledig plads
Jeg starter ofte med en simpel planlægningsfunktion som ingen eller mq-deadline og tilpasser I/O-dybden efter den enkelte arbejdsbelastning for at udfylde køerne på en fornuftig måde. En for høj dybde skaber spidsbelastninger i latenstiden, mens en for lav dybde spilder parallelle ressourcer. At afsætte 15–20 % ledig plads reducerer fragmentering og sikrer hurtige allokeringer. For XFS ser jeg på fordelingen i allokeringsgrupper, da de i høj grad præger filsystemets parallelitet; et godt sted at starte er XFS-allokeringsgrupper. Jeg måler hver ændring ved hjælp af en A/B-sammenligning, så effekterne forbliver gennemsigtige, og der ikke slipper nogen forringelser igennem.
Målrettet brug af monteringsmuligheder
Mount-indstillinger påvirker journalføring, commit-intervaller og skriveveje og kan påvirke latenstid og gennemstrømning mærkbar flytte. EXT4 tilbyder nyttige indstillingsmuligheder for journal-tilstand og commit-tider, mens XFS har indstillinger for logbuffere og inode-parametre. Jeg tilpasser disse indstillinger efter belastningsprofilen og dokumenterer hver ændring. Hvis du vil dykke dybere ned i emnet, finder du kortfattede tip til nyttige parametre i EXT4-monteringsindstillinger. Det er stadig vigtigt at teste enhver justering af monteringen med reelle arbejdsbelastninger, ikke kun med syntetiske tests.
Hosting i praksis: Valg ud fra arbejdsbelastning
Til klassiske webapplikationer med CMS og webshops leverer EXT4 en pålidelig Basis, fordi der er mange små filer og blandede I/O-mønstre. Databaser med høj parallelitet kører meget godt på begge filsystemer; jeg træffer min beslutning ud fra eksisterende erfaringer, overvågningsopsætningen og backup-konceptet. Store sekventielle datastrømme ved sikkerhedskopieringer og arkivering favoriserer XFS, hvilket strammer overførselsvinduerne op. Analysearbejdsbelastninger drager også fordel af XFS’ håndtering af store scanninger, mens blandede profiler ofte viser næsten ingen forskelle. Hvis man er usikker, kan man oprette et staging-system og måle under de vigtigste daglige belastninger.
Teststrategi: realistisk og målbar
Jeg kombinerer korte spidsbelastningstests med lange udholdenhedsløb, så jeg kan måle både maksimale værdier samt jitter og aldringseffekter se. I stedet for blot at bruge syntetiske værktøjer benytter jeg kopier af produktive databaser, typiske logfiler og reelle import-/eksportopgaver. Overvågning med iostat, perf og applikationsmetrikker kører altid i baggrunden, så jeg entydigt kan påvise sammenhænge. Jeg gentager testene efter kerneopdateringer eller firmwareændringer for tidligt at opdage regressioner. På den måde viser det sig, om XFS eller EXT4 i mit eget miljø leverer det bedste kompromis mellem gennemstrømning, latenstid og forudsigelighed (kilde: 1).
Journalføring, barrierer og synkroniseringssemantik på NVMe
Journaliseringsdetaljer er med til at bestemme spidsbelastninger og gendannelsesadfærd. EXT4 bruger som standard data=ordnet og skriver metadata til journalen, mens brugsdata gemmes før commit. Hvis man har brug for maksimal skrivehastighed med et acceptabelt risikoniveau, kan man data=tilbageskrivning overveje, hvilket dog gør det vanskeligere at afspille replays efter nedbrud. Nyere EXT4-versioner understøtter fast_commit, hvilket samler mange små metadatatransaktioner og forkorter commit-tiderne. XFS fører sin egen log (journal), hvis logbstørrelse og logbuffer har en betydelig indflydelse på parallelitet og latenstid. På NVMe er Skrivebarrierer Vigtigt: Uden Power-Loss-Protection (PLP) bør barrierer forblive aktive for at sikre, at controller-firmwaren ikke omordnes. Med PLP kan man målrettet reducere barrierer for at fremskynde fsync()-tunge belastninger – man skal dog altid afveje dette mod risikoen. For applikationer med strenge krav til holdbarhed (f.eks. databaser) er en korrekt fsync()-adfærd vigtigere end et par procentpoint mere i gennemstrømning.
TRIM/Discard og NVMe’s langsigtede adfærd
Påvirke Flash Fjern/Beskær-Strategier, der sikrer en stabil skriveydelse. Inline-discard ved mount (discard/async_discard) reducerer controllerens baggrundsarbejde, men kan forårsage latensspidser under belastning. Periodisk fstrim-Kørsler (f.eks. ugentligt) sikrer i mange produktionsmiljøer en mere stabil ydeevne og adskiller frigivelsen af ubrugte blokke fra hot-path’en. XFS behandler discard-operationer effektivt i batches, mens EXT4 tilbyder med discard=async en blød variant. Det er vigtigt, at Discard videregives korrekt gennem alle lag (dm-crypt, LVM, MD-RAID, hypervisor). Hvis der på lang sigt holdes 15–20 %-reserve fri, reduceres den interne garbage collection – latenstjitteret falder, og skriveydelsen forbliver mere stabil.
RAID, LVM og kryptering: At afstemme lagene korrekt
Inden formateringen bør blokgeometrien passe til RAID/LVM. For XFS afhænger det rigtige valg af sunit/swidth (Allocation-Alignment) effektiviteten af store sekventielle overførsler; i EXT4 sker dette ved hjælp af stride/stribe-bredde. Hvis justeringen er korrekt, minimeres »read-modify-write«-cyklusserne i RAID. LVM-Thin og snapshots er praktiske, men øger latenstiden i skrivestier – dette har større betydning ved tilfældige arbejdsbelastninger end ved rene scanninger. dm-krypt/LUKS belaster CPU’en og kan begrænse IOPS ved små blokke; moderne AES-NI/ARM-Crypto hjælper, men latenserne i slutningen stiger typisk en smule. For krypterede diskenheder kan det betale sig at justere I/O-dybden og kø-affiniteterne og eksplicit tillade discard, hvis sikkerhedsretningslinjerne tillader det.
CPU/NUMA, interrupt-affinitet og io_uring: Finjustering af latenstid
NVMe skalerer via flere submission/completion-køer; hvem NUMA-placering Bemærk, at dette reducerer antallet af hop på tværs af noder. NVMe-IRQ’er og applikationens arbejdstråde bør køre på den samme NUMA-node, hvor hukommelsen er allokeret. I Linux kan IRQ-pinning og tilpassede rps/xps-Indstillinger, der sikrer, at datastien forbliver lokal. Moderne arbejdsbelastninger drager fordel af io_uring (i stedet for den ældre AIO), som reducerer antallet af systemkald og muliggør batch-indsendelse. I fio-tests viser dette sig som lavere latenstider ved samme IOPS. For store kødybder (iodepth) forvrænger imidlertid latensfordelingen; det er derfor hensigtsmæssigt at gennemføre trinvise tests (f.eks. 1, 4, 16, 64) for at identificere det optimale punkt for hver arbejdsbelastning.
Container- og VM-miljøer: Særlige forhold i stakken
Inden for containere (overlayfs) har XFS længe været det foretrukne valg, fordi d_type var tidligt tilgængeligt og pålideligt, og store lag-sæt blev administreret effektivt. I dag leverer moderne EXT4-implementeringer tilsvarende stabilitet; forskellene i ydeevne er små og skyldes snarere overlayfs end selve filsystemet. I virtuelle maskiner dominerer hypervisorens Virtio-/NVMe-frontends og caching-tilstande: cache=none plus O_DIRECT i gæsten reducerer dobbeltbuffering. Det er vigtigt, at Discard-aflevering og ensartede sektorstørrelser (4K vs. 512e) for at undgå skriveforstærkning. Snapshot-baserede platforme (f.eks. QCOW2, ZVOL) implementerer Copy-on-Write; valget af filsystem i gæsten forbliver relevant, men værtsbackendet sætter ofte grænser tidligere end XFS/EXT4 selv.
Gendannelse, konsistens og vedligeholdelsesvindue
Begge filsystemer anses for at være robuste, men Vedligeholdelsesruter adskiller sig fra hinanden. EXT4 kan kontrolleres grundigt med e2fsck; på meget store volumener tager det mærkbart lang tid, hvis der er fejl, men systemet drager fordel af inkrementelle forbedringer (Fast-Commit forkorter replay af mindre transaktioner). XFS er på Konsistens på nettet konfigureret; dybe kontroller udføres med xfs_repair, som i alvorlige tilfælde kræver meget RAM og kan tage lang tid ved meget store træstrukturer. For produktive systemer er det en god idé at fsfreeze før LVM-/storage-snapshots for at opnå applikationskonsistente sikkerhedskopier; databaser bør desuden udløse deres egne checkpoint-/backup-mekanismer. Hvis man har SLA'er med korte RTO/RPO-krav, skal man udtrykkeligt planlægge gendannelsestests – det afmystificerer myter og viser realistiske nedetidsvinduer.
Funktionsmæssige aspekter ud over den rene ydeevne
Ydeevne er ikke alt. XFS tilbyder Reflink-baserede kopier og deduplikations-hooks, hvilket sparer lagerplads og forkorter kopieringstiden for VM-images og store mediebestande. EXT4 udmærker sig ved bred værktøjsunderstøttelse og konservative standardindstillinger, der forenkler udrulningen. Kvoter findes i begge verdener; XFS udmærker sig ved Projekt-kvoter til mappe-baserede kvoter i store multitenant-strukturer. Muligheder som noatime/relatime/lazytime reducerer metadata-skrivebelastningen mærkbart. Hvis man bruger kryptering pr. mappe eller pr. fil (fscrypt), bør man tage højde for den lille ekstra belastning ved små tilfældige adgangsforespørgsler og sørge for at have CPU-reserver til rådighed.
Sådan undgår du målefejl: typiske faldgruber
Mange af de formodede forskelle mellem FS er i virkeligheden Testartefakter. For små datasæt havner i sidecachen og skjuler forskelle; datasæt bør være større end den tilgængelige RAM. Et manglende opvarmning forvrænger Random-Write-profiler på flash; ligeledes medfører vedligeholdelsesopgaver, der kører parallelt (scrubs, rebuilds, fstrim), afvigelser. Ved fio-tests skal det være klart, om direct=1 Det undersøges, om fsync()-faser er indstillet realistisk, og om blandede læse-/skriveoperationer kører interleaved eller i faser. For at opnå reproducerbare resultater kræves faste CPU-frekvenser (ingen aggressive skaleringsregulatorer), konstant baggrundsbelastning og en klar adskillelse mellem test og overvågning.
Tjekliste til praksis: Sådan gør du
- Afklare arbejdsbyrdens profil: Blokstørrelser, læse/skrive-forhold, latenstid, burst-adfærd.
- Rydde op i stakken: Kernel, NVMe-firmware, driverversioner; kontroller IRQ-affinitet og NUMA.
- Justere layout: Indstil RAID-/LVM-alignment (sunit/swidth henholdsvis stride/stripe-width) korrekt.
- Test af monteringsmuligheder: Barrierer, commit-intervaller, noatime/relatime/lazytime; XFS-log-parametre.
- Kalibrering af I/O-dybde: Afveje latenstid mod gennemstrømning og find det optimale punkt for hver applikation.
- Sørg for at have ledig plads: 15–20 % Reserve for ensartede latenstider og mindre fragmentering.
- Definer en discard-strategi: Inline vs. periodisk fstrim, der udbredes gennem alle lag.
- Sikkerhedskopiering og gendannelse: Test af fsfreeze-/Snapshot-processer, realistisk verifikation af nedetid.
- A/B-målinger: Ændr kun én variabel, og sammenlign resultaterne med applikationsmetrikkerne.
Resumé: Beslutningsstøtte uden myter
XFS og EXT4 leverer meget høj ydeevne på NVMe, men forskellene forbliver for det meste moderat og afhænger i høj grad af I/O-profilen. Tilfældige belastninger med små blokke ligger tæt på hinanden, mens lange sekventielle strømme har en tendens til at give XFS en fordel. EXT4 udmærker sig med en lidt højere gennemstrømning i visse transaktionsmønstre, mens XFS udviser konstante ventetider under langvarige test. Kernelversion, NVMe-modeller, scheduler, I/O-dybde, ledig plads og monteringsindstillinger påvirker ofte resultatet i højere grad end valget af filsystem alene. Den, der måler præcist og forstår sine egne arbejdsbelastninger, træffer en velbegrundet beslutning – uden myter og med målbare Overskud.
