XFS versus EXT4 op NVMe-servers: benchmarks en praktijkvergelijking

Ik vergelijk XFS EXT4 op NVMe-servers aan de hand van actuele benchmarks en praktijkcijfers, en laat ik zien wanneer welk bestandssysteem meetbaar beter presteert. Daarbij richt ik me op doorvoersnelheid, latentie en reële workloads, zodat je de NVMe-prestaties op de server doelgericht kunt benutten.

Centrale punten

Om te beginnen zal ik de belangrijkste bevindingen kort samenvatten, voordat ik inga op de details, benchmarks en optimalisatie.

• Willekeurige I/O: Beide liggen heel dicht bij elkaar; EXT4 heeft een iets hogere doorvoersnelheid, XFS heeft gelijkmatigere latenties.
• Sequentieel: XFS presteert vaak het beste bij grote bestanden, EXT4 volgt op korte afstand met solide snelheden.
• Metagegevens: EXT4 biedt hier en daar kleine voordelen, XFS heeft constante responstijden.
• Toepassingen: In de databases gaan ze nek aan nek, met verschillen van slechts enkele procenten.
• Afstemmen: De kernel, de scheduler, de I/O-diepte, de vrije ruimte en de mount-opties maken het verschil.

XFS en EXT4 op NVMe: technische toelichting

EXT4 wordt beschouwd als een beproefde Linux-standaard en levert op NVMe een zeer betrouwbare Het vormt de basis en dient in veel vergelijkingen als referentie. XFS is geschikt voor grote bestanden, hoge mate van parallelliteit en sequentiële gegevensstromen, en kan de doorvoercapaciteit van NVMe zeer goed benutten. Op moderne hardware worden de verschillen kleiner, omdat beide bestandssystemen jarenlang zijn doorontwikkeld en nieuwe kernelversies de NVMe-stack verder optimaliseren. Bij alledaagse workloads zijn het vaak de belastingprofielen die de doorslag geven: bij veel kleine, willekeurige toegangen die dicht op elkaar volgen, zijn grote sequentiële overdrachten doorgaans beter geschikt voor XFS. Wie beslissingen neemt, moet daarom zijn I/O-profiel kennen en niet alleen uitgaan van algemene Ranglijsten kijken.

Willekeurige I/O op NVMe: kleine blokken, hoge mate van parallelliteit

Bij 4K- en 8K-toegangen leveren beide bestandssystemen IOPS op een zeer soortgelijke Niveau, vaak binnen enkele procentpunten. EXT4 laat in sommige metingen iets hogere gemiddelden zien bij willekeurig schrijven, wat zichtbaar kan zijn in OLTP-achtige scenario’s. XFS blinkt daarentegen uit met gelijkmatigere latenties en minder jitter over langere looptijden, wat bij gemengde belastingen voorspelbare responstijden bevordert. In productieomgevingen worden deze subtiele verschillen vaak gemaskeerd door caches, applicatielogica en netwerkpaden. Daardoor komen andere instellingen, zoals de buffer-cache, WAL-strategie of I/O-diepte, op de voorgrond (bron: 1, 4, 7).

Sequentiële overdrachten: grote bestanden efficiënt verplaatsen

Bij blokken ter grootte van een MB en lange, sequentiële streams heeft XFS vaak een voorsprong, omdat de indeling van de extents grote bestanden efficiënt beheerd. Back-upvensters, archiveringsopdrachten en sequentiële checkpoints profiteren hier merkbaar van, vooral op PCIe 4.0/5.0 NVMe. EXT4 blijft dicht in de buurt en levert zeer goede snelheden, die in veel opstellingen nauwelijks een beperking vormen. Hoe langer de stream en hoe groter het bestand, hoe duidelijker het voordeel naar XFS doorslaat. Een aanvullend overzicht biedt mijn korte Prestatievergelijking met typische serverworkloads (bron: 4, 5, 9).

Metadata-bewerkingen: veel kleine bestanden

Workloads met veel bestandsbewerkingen stellen hoge eisen aan de metadatapaden en leiden tot verschillen op het gebied van vergrendeling en journaling Licht. EXT4 komt in sommige tests net iets beter uit de bus bij het snel aanmaken en verwijderen van veel kleine bestanden. XFS houdt daarentegen stand met constante latenties en blijft daardoor goed inzetbaar voor logbestanden, caches en build-mappen. In vergelijking met alternatieve bestandssystemen vertonen beide een volwassen beheer en voorspelbare reactiepatronen. Wie grote hoeveelheden kleine bestanden verplaatst, moet rekening houden met de mount-opties en praktijkgerichte tests over langere perioden uitvoeren (bron: 1, 7, 13).

Overzicht van benchmarks in cijfers

Ik vat de volgende trends kort samen, zodat je snel de typische patronen kunt herkennen herkennen. Willekeurige I/O met kleine blokken: de verschillen zijn meestal klein, vaak in de orde van ±3–5 % bij IOPS. Sequentiële I/O met grote blokken: XFS ligt vaak voorop, vooral bij lange streams en grote bestanden. Metadata-intensieve tests: soms een klein voordeel voor EXT4, XFS met gelijkmatige latenties. In analytische scenario’s benutten beide bestandssystemen vaak ongeveer 80–85 % van de theoretische NVMe-prestaties, afhankelijk van de kernel, het stuurprogramma en de firmware van de controller (bron: 1, 3, 4, 5, 10).

Scenario	Neiging	Typisch voordeel	Tip
Willekeurige I/O (4K/8K)	Heel nauw	EXT4 heeft een iets hogere doorvoersnelheid	XFS heeft vaak lagere latenties
Sequentieel (≥1 MB)	XFS aan kop	Hogere doorvoersnelheid bij grote bestanden	Lange streams versterken het effect
Metadata-bewerkingen	Nek aan nek	EXT4 is deels sneller bij het aanmaken en verwijderen van bestanden	XFS blijft stabiel bij een gemengde belasting
Databases (OLTP)	Heel nauw	EXT4: iets hogere TPS	XFS zorgt voor gelijkmatigere responstijden
Analytics/Rapportage	Eng	XFS bij grote scans	Beide maken gebruik van 80–85 % van de HW

Toepassingsgerichte benchmarks: databases en gemengde belasting

In PostgreSQL- of MySQL-tests zie ik een nek-aan-nekrace die wordt bepaald door latentieprofielen, WAL-strategieën en buffer-cache-instellingen leeft. EXT4 levert soms net iets meer transacties per seconde bij een hoge mate van parallelliteit. XFS blinkt uit door stabiele responstijden, wat de staartlatenties in kritieke API’s kan afvlakken. De verschillen blijven zo klein dat het optimaliseren van de database meer effect heeft dan alleen het wisselen van bestandssysteem. Wie de beslissing neemt, moet daarom typische langdurige werkbelastingen meten en de applicatiestatistieken zorgvuldig in de gaten houden (bron: 2, 3, 9).

Kernelversie, NVMe-modellen en hun invloed

Nieuwere Linux-kernels uit de 5.x- en 6.x-series verminderen de latentie en verhogen de doorvoersnelheid, wat beide bestandssystemen op snelle NVMe ten goede komt en knelpunten in de I/O-stack wegneemt vermindert. Enterprise-SSD’s met een grote DRAM-cache en bescherming tegen stroomuitval verdoezelen de verschillen nog meer, omdat de controller en firmware al beperkingen opleggen voordat het bestandssysteem een rol gaat spelen. Goedkope NVMe-schijven voor consumenten laten het verschil duidelijker zien, maar presteren in het dagelijks gebruik meestal vrij dicht bij elkaar. PCIe 4.0/5.0 vergroot de headroom, waardoor de sequentiële voordelen van XFS beter zichtbaar worden. Kernel-updates, NVMe-firmware en goed bijgewerkte stuurprogramma’s leveren daarom meetbare voordelen op (bron: 1, 5, 10, 11).

Optimalisatie voor NVMe: scheduler, I/O-diepte, vrije ruimte

Ik begin vaak met een eenvoudige planner zoals geen of mq-deadline en pas de I/O-diepte per workload aan om wachtrijen op een zinvolle manier te vullen. Een te hoge diepte veroorzaakt piekwaarden in de latentie, een te lage diepte verspilt parallelle resources. Door 15–20 % vrije ruimte in te plannen, wordt fragmentatie verminderd en blijven toewijzingen soepel verlopen. Voor XFS bekijk ik de indeling in Allocation Groups, omdat deze de parallelliteit van het bestandssysteem in belangrijke mate beïnvloeden; een goed instaponderwerp zijn de XFS-toewijzingsgroepen. Ik meet elke wijziging aan de hand van een A/B-vergelijking, zodat de effecten traceerbaar blijven en er geen verslechteringen onopgemerkt blijven.

Gericht gebruikmaken van bevestigingsopties

Mount-opties beïnvloeden journaling, commit-intervallen en schrijfpaden en kunnen de latentie en doorvoersnelheid merkbaar aanpassen. EXT4 biedt handige instellingen voor de journaalmodus en commit-tijden, terwijl XFS opties biedt voor logbuffers en inode-parameters. Ik pas deze instellingen aan op basis van het belastingprofiel en documenteer elke wijziging. Wie zich hier verder in wil verdiepen, vindt beknopte aanwijzingen over nuttige parameters in de EXT4-koppelingsopties. Het blijft belangrijk om elke aanpassing aan de mount te toetsen aan de hand van echte workloads, en niet alleen met synthetische tests.

Hosting in de praktijk: keuze op basis van de werklast

Voor klassieke webapplicaties met CMS en webwinkels biedt EXT4 een betrouwbare Basis, omdat er veel kleine bestanden en gemengde I/O-patronen de boventoon voeren. Databases met een hoge mate van parallelliteit draaien op beide bestandssystemen zeer goed; ik baseer mijn keuze op bestaande ervaringen, de monitoringopstelling en het back-upconcept. Grote sequentiële gegevensstromen bij back-ups en archieven zijn gunstig voor XFS, wat de overdrachtsvensters versnelt. Analytics-workloads profiteren eveneens van de manier waarop XFS omgaat met grote scans, terwijl gemengde profielen vaak nauwelijks verschillen vertonen. Wie twijfelt, zet een staging-systeem op en meet de prestaties tijdens de belangrijkste dagelijkse pieken.

Teststrategie: realistisch en meetbaar

Ik combineer korte piekproeven met lange duurloopjes, zodat ik zowel maximale waarden als jitter en verouderingseffecten zie. In plaats van alleen synthetische tools gebruik ik kopieën van productieve databases, typische logbestanden en echte import-/exporttaken. Monitoring met iostat, perf en applicatiestatistieken draait altijd mee, zodat ik correlaties ondubbelzinnig kan aantonen. Ik herhaal de tests na kernel-updates of firmwarewijzigingen om regressies vroegtijdig op te sporen. Zo wordt duidelijk of XFS of EXT4 in de eigen omgeving het betere compromis biedt tussen doorvoersnelheid, latentie en voorspelbaarheid (bron: 1).

Journaling, barrières en synchronisatiesemantiek op NVMe

De details van het logboek zijn mede bepalend voor pieken in de latentie en het herstelgedrag. EXT4 maakt standaard gebruik van data=geordend en schrijft metadata naar het logboek, terwijl gebruiksgegevens vóór de commit worden opgeslagen. Wie een maximale schrijfsnelheid nodig heeft bij een aanvaardbaar risico, kan data=writeback overwegen, wat het echter moeilijker maakt om na crashes herhalingen te bekijken. Nieuwere EXT4-versies ondersteunen fast_commit, waardoor veel kleine metadatatransacties worden gebundeld en de commit-tijden worden verkort. XFS houdt een eigen logboek (journal) bij, waarvan de logbsgrootte en logbufs de parallelliteit en de latentie aanzienlijk beïnvloeden. Op NVMe zijn Schrijfbarrières Belangrijk: zonder Power-Loss-Protection (PLP) moeten barrières actief blijven om de volgorde van de controllerfirmware te waarborgen. Met PLP kun je barrières gericht verminderen om taken met veel fsync()-bewerkingen te versnellen – weeg dit altijd af tegen het risico. Voor toepassingen met strenge eisen op het gebied van duurzaamheid (bijv. databases) is een correct fsync()-gedrag belangrijker dan een paar procentpunten extra doorvoer.

TRIM/Discard en het gedrag van NVMe op lange termijn

Invloed uitoefenen op Flash Verwijderen/Bijsnijden-Strategieën voor duurzame schrijfprestaties. Inline-discard bij het mounten (discard/async_discard) vermindert het achtergrondwerk van de controller, maar kan bij hoge belasting pieken in de latentie veroorzaken. Periodieke fstrim-Runs (bijv. wekelijks) zorgen er in veel productieomgevingen voor dat de prestaties constanter blijven en ontkoppelen het vrijgeven van ongebruikte blokken van het hot-path. XFS verwerkt discards efficiënt in batches, EXT4 biedt met discard=async een zachte variant. Het is belangrijk om ‘Discard’ netjes door alle lagen (dm-crypt, LVM, MD-RAID, hypervisor) door te geven. Als er op lange termijn 15–20 %-reserve wordt vrijgehouden, neemt de interne garbage collection af – de latentiejitter daalt en de schrijfprestaties blijven stabieler.

RAID, LVM en versleuteling: de lagen goed op elkaar afstemmen

Voordat je gaat formatteren, moet de blokgeometrie overeenkomen met RAID/LVM. Voor XFS bepaalt de juiste keuze van sunit/swidth (Allocation-Alignment) de efficiëntie van grote sequentiële overdrachten; bij EXT4 gebeurt dit door stride/streepbreedte. Als de uitlijning correct is, worden de read-modify-write-cycli in het RAID-systeem geminimaliseerd. LVM-Thin en snapshots zijn handig, maar verhogen de latentie in schrijfpaden – dat speelt bij willekeurige workloads een grotere rol dan bij puur scannen. dm-crypt/LUKS kost CPU-capaciteit en kan bij kleine blokken de IOPS beperken; moderne AES-NI/ARM-Crypto helpen, maar de tail-latenties nemen doorgaans licht toe. Voor versleutelde volumes loont het de moeite om de I/O-diepte en wachtrij-affiniteiten opnieuw in te stellen en ‘discard’ expliciet toe te staan, mits de beveiligingsrichtlijnen dit toestaan.

CPU/NUMA, interrupt-affiniteit en io_uring: fijnafstemming van de latentie

NVMe schaalt via meerdere submission/completion-wachtrijen; wie NUMA-locatie Let op: dit vermindert het aantal hops tussen knooppunten. NVMe-IRQ’s en de werkthreads van de applicatie moeten op hetzelfde NUMA-knooppunt draaien als waar het geheugen is toegewezen. In Linux helpen IRQ-pinning en aangepaste rps/xps-Instellingen om het gegevenspad lokaal te houden. Moderne workloads profiteren van io_uring (in plaats van de oudere AIO), die het aantal syscalls vermindert en het indienen van batches mogelijk maakt. In fio-tests komt dit tot uiting in lagere latenties bij een gelijk aantal IOPS. Te hoge wachtrijdieptes (iodepth) zorgen echter voor een onduidelijke verdeling van de latentie; het is zinvol om getrapte tests uit te voeren (bijv. 1, 4, 16, 64) om de ‘sweet spot’ per workload te bepalen.

Container- en VM-omgevingen: bijzonderheden in de stack

Op het gebied van containers (overlayfs) was XFS lange tijd de standaardkeuze, omdat d_type vroeger al betrouwbaar beschikbaar was en grote layersets efficiënt werden beheerd. Tegenwoordig bieden moderne EXT4-implementaties een vergelijkbare stabiliteit; de prestatieverschillen zijn klein en worden eerder door overlayfs dan door het bestandssysteem zelf bepaald. In VM’s spelen de Virtio-/NVMe-frontends en cachingmodi van de hypervisor de hoofdrol: cache=none plus O_DIRECT in de gast vermindert double-buffering. Belangrijk zijn Discard-doorgeven en uniforme sectorgroottes (4K versus 512e) om schrijfversterking te voorkomen. Snapshot-gestuurde platforms (bijv. QCOW2, ZVOL) passen Copy-on-Write toe; de keuze van het bestandssysteem in de gast blijft relevant, maar de host-backend bereikt vaak eerder zijn limiet dan XFS/EXT4 zelf.

Herstel, consistentie en onderhoudsvensters

Beide bestandssystemen worden als robuust beschouwd, maar de Onderhoudsroutes verschillen van elkaar. EXT4 kan grondig worden gecontroleerd met e2fsck; bij zeer grote volumes duurt dit bij fouten merkbaar lang, maar het profiteert wel van incrementele verbeteringen (Fast-Commit verkort het opnieuw afspelen van kleinere transacties). XFS is op Consistentie online ingesteld; diepgaande controles worden uitgevoerd met xfs_repair, dat in ernstige gevallen veel RAM vereist en bij zeer grote boomstructuren veel tijd in beslag kan nemen. Voor productieve systemen is het de moeite waard om fsfreeze vóór LVM-/opslagsnapshots, om applicatieconsistente back-ups te verkrijgen; databases moeten bovendien hun eigen checkpoint-/back-upmechanismen activeren. Wie SLA's met korte RTO's/RPO's heeft, plant expliciet hersteltests in – dit ontkracht mythes en toont realistische downtime-vensters.

Functieaspecten die verder gaan dan pure prestaties

Prestaties zijn niet alles. XFS biedt Reflink-gebaseerde kopieën en deduplicatie-hooks, wat bij VM-images en grote mediabestanden opslagruimte bespaart en de kopieertijden verkort. EXT4 blinkt uit door uitgebreide ondersteuning voor tools en conservatieve standaardinstellingen, die implementaties vereenvoudigen. Quota zijn in beide werelden beschikbaar; XFS blinkt uit met Project-Quota's voor op mappen gebaseerde quota’s in grote multitenant-structuren. Opties zoals noatime/relatime/lazytime verminderen de schrijfbelasting van metagegevens merkbaar. Wie versleuteling per map of per bestand (fscrypt) gebruikt, moet rekening houden met de lichte overhead bij kleine willekeurige toegangen en CPU-reserves aanhouden.

Meetfouten voorkomen: veelvoorkomende valkuilen

Veel vermeende verschillen tussen FS zijn in werkelijkheid Testartefacten. Te kleine datasets komen in de paginacache terecht en verdoezelen verschillen; datasets moeten groter zijn dan het beschikbare RAM-geheugen. Een ontbrekend opwarming vervalsen de willekeurige-schrijfprofielen op flash; ook leiden parallel lopende onderhoudstaken (scrubs, rebuilds, fstrim) tot uitschieters. Bij fio-tests moet duidelijk zijn of direct=1 wordt gecontroleerd of de fsync()-fasen realistisch zijn ingesteld en of de combinatie van lees- en schrijfbewerkingen geïnterleaved verloopt of in fasen plaatsvindt. Voor reproduceerbare resultaten zijn vaste CPU-frequenties (geen agressieve scaling-governors), een constante achtergrondbelasting en een duidelijke scheiding tussen test en monitoring vereist.

Checklist voor de praktijk: zo ga je te werk

• Het workloadprofiel verduidelijken: blokgroottes, lees/schrijf-verhouding, latentiebudget, burst-gedrag.
• Stack opschonen: kernel, NVMe-firmware, stuurprogramma-versies; IRQ-affiniteit en NUMA controleren.
• Lay-out uitlijnen: De RAID-/LVM-uitlijning (sunit/swidth of stride/stripe-width) correct instellen.
• Mount-opties testen: Barrières, commit-intervallen, noatime/relatime/lazytime; XFS-logparameters.
• I/O-diepte kalibreren: Afwegen tussen latentie en doorvoersnelheid, de optimale balans per toepassing vinden.
• Zorg voor voldoende ruimte: 15–20 % Reserve voor gelijkmatige latenties en minder fragmentatie.
• Discard-strategie definiëren: Inline versus periodiek fstrim, door alle lagen heen doorvoeren.
• Back-ups en herstel: fsfreeze-/snapshot-processen testen, de downtime op realistische wijze controleren.
• A/B-metingen: Slechts één variabele wijzigen, resultaten correleren met applicatiestatistieken.

Samenvatting: Beslissingshulp zonder mythes

XFS en EXT4 leveren op NVMe zeer hoge prestaties; de verschillen blijven meestal matig en zijn sterk afhankelijk van het I/O-profiel. Willekeurige belastingen met kleine blokken liggen dicht bij elkaar, terwijl lange sequentiële streams XFS doorgaans een voorsprong geven. EXT4 overtuigt met een iets hogere doorvoer in sommige transactionele patronen, XFS met constante latenties tijdens langdurige tests. De kernelversie, NVMe-modellen, schedulers, I/O-diepte, beschikbare ruimte en mount-opties beïnvloeden het resultaat vaak sterker dan de keuze voor het bestandssysteem alleen. Wie nauwkeurig meet en zijn eigen workloads begrijpt, neemt een weloverwogen beslissing – zonder mythes en met meetbare Winst.