Wat ext4 anders maakt

`mkfs.ext4 /dev/sda1` — dat commando draait op vrijwel elke Linux-server, van een Raspberry Pi tot een rackunit in een datacenter. Dit artikel legt uit wat ext4 anders maakt dan zijn voorgangers, waar de grenzen liggen en hoe je een ext4-volume opzet en controleert.

Vereisten

Je hebt een Linux-systeem nodig met kernel 2.6.28 of nieuwer — dat is elke distributie die sinds 2009 is uitgebracht. Verder heb je root-toegang nodig en een ongebruikte partitie of disk waarop je een bestandssysteem wilt aanmaken. Voor de voorbeelden in dit artikel gebruik ik Ubuntu 24.04 LTS, maar de commando's werken ongewijzigd op Debian, RHEL, Rocky en de meeste andere distributies. De `e2fsprogs`-pakketversie moet 1.42 of hoger zijn; dat controleer je met `e2fsprogs --version`.

Wat ext4 anders maakt

ext4 is geen nieuw ontwerp, maar een evolutionaire stap vanaf ext3. De kernel-documentatie noemt het dan ook een "extending" bestandssysteem: het behoudt de structuur van zijn voorganger en voegt er functionaliteit aan toe. Die aanpak heeft één groot voordeel: je kunt een bestaand ext3-volume upgraden zonder opnieuw te formatteren. Je gegevens blijven staan, de partitie-tabel blijft intact, en je wint de nieuwe mogelijkheden erbij.

De kernverbetering zit in de manier waarop ext4 bestanden op de schijf bijhoudt. ext2 en ext3 gebruikten een block map: een lijst van alle individuele blokken die een bestand beslaat. Bij grote bestanden wordt die lijst lang, en dat kost metadata en tijd. ext4 gebruikt in plaats daarvan extents: aaneengesloten reeksen blokken die je als één geheel registreert. Een bestand van 100 MB beschrijf je dan niet met tienduizenden losse blokverwijzingen, maar met een handvol extent-verwijzingen. Vooral bij het lezen en schrijven van grote bestanden levert dat winst op.

Daarnaast registreert ext4 timestamps met nanoseconde-precisie, waar ext3 bleef steken op seconden. Dat lijkt een detail, maar voor auditlogging en toepassingen die exacte tijdsregistratie nodig hebben, is het verschil tussen seconden en nanoseconden het verschil tussen een vermoeden en een bewijs.

Journaling: de vangrail van ext4

ext4 erft het journaalmechanisme van ext3. Het principe: voordat het bestandssysteem metadata wijzigt, schrijft het die wijziging eerst weg naar een log — het journaal. Pas daarna voert het de wijziging daadwerkelijk uit. Gaat het systeem halverwege dood door een stroomstoring of een kernel panic, dan kan het bestandssysteem bij de volgende mount het journaal terugspoelen en de metadata herstellen naar een consistente staat. Zonder journaal zou je na elke crash een volledige `fsck` moeten draaien en hopen dat er niets verloren is gegaan.

ext4 kent drie journaalmodi, die elk een ander compromis vormen tussen snelheid en veiligheid:

• `writeback` journalt alleen metadata, niet de bestandsinhoud. Snel, maar na een crash kan een bestand metadata bevatten die verwijst naar data die nooit is weggeschreven.
• `ordered` (de standaard) journalt ook alleen metadata, maar dwingt af dat de datablokken vóór de bijbehorende metadata naar de schijf gaan. Een bestand dat na een crash verschijnt, bevat dan geen rommel.
• `journal` schrijft alle data eerst naar het journaal en pas daarna naar de uiteindelijke plek. Veiligst, maar ook het traagst, omdat elke schrijfactie twee keer plaatsvindt.

De `ordered`-modus is voor de meeste workloads de juiste keuze: de veiligheid van consistente metadata zonder de prestatiekosten van volledige journaling. Voor databases die hun eigen transactional gedrag hebben, kan `writeback` een optie zijn — maar alleen als je weet wat je opgeeft.

De grenzen van ext4

ext4 ondersteunt volumes tot 1 exbibyte (EiB) en individuele bestanden tot 16 tebibyte (TiB), volgens de specificaties die Oracle aanhoudt. Die limieten liggen in de praktijk ver buiten wat je op één filesystem zet — de meeste servers draaien met volumes van enkele terabytes.

Wat ext4 niet heeft, is copy-on-write. Bestandssystemen als Btrfs en ZFS schrijven data nooit over de bestaande blokken heen, maar naar nieuwe blokken en schakelen dan pas om. Dat maakt snapshots mogelijk, ingebouwde compressie en checksum-controle over het hele datapad. ext4 heeft dat allemaal niet. Wil je een snapshot van een ext4-volume maken, dan moet je dat op een ander niveau oplossen — met LVM-snapshots, of met een backup-tool die op bestandsniveau werkt.

Dat klinkt als een gemis, maar het is ook een keuze voor eenvoud. Copy-on-write-bestandssystemen zijn complexer, verbruiken meer geheugen en hebben een langere leercurve. Op een standaard server waar je gewoon een betrouwbaar bestandssysteem wilt dat geen verrassingen oplevert, is die complexiteit vaak niet nodig.

Een ext4-volume opzetten

De stappen hieronder nemen je mee van een kale partitie naar een gemount ext4-volume dat bij elke reboot automatisch beschikbaar is.

1. Identificeer de juiste disk lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT Dit toont alle disks en partities met hun huidige bestandssysteem. Noteer de naam van de partitie die je wilt formatteren — bijvoorbeeld `/dev/sdb1`. Dubbelcheck of je de juiste disk te pakken hebt. Een verkeerd device formatteren betekent gegarandeerd gegevensverlies, en daar is geen undo voor.

2. Maak het ext4-bestandssysteem aan sudo mkfs.ext4 /dev/sdb1 Dit commando formatteert de partitie met ext4. Voeg `-L datavolume` toe om een label te geven — handig als je later meerdere volumes beheert en niet wilt raden welke disk welke is. Het commando vraagt bevestiging als het device al een bestandssysteem bevat. Lees die melding, typ `y`, en alleen dan gebeurt er iets.

3. Maak een mountpoint sudo mkdir -p /mnt/data Dit is de directory waar het bestandssysteem zichtbaar wordt. Kies een naam die beschrijft wat erop komt te staan. Een mountpoint als `/mnt/backup` vertelt je over drie maanden nog steeds wat er op die disk hoort te staan; `/mnt/data1` niet.

4. Mount het bestandssysteem sudo mount /dev/sdb1 /mnt/data De partitie is nu bereikbaar via `/mnt/data`. Controleer met `df -h /mnt/data` of het volume correct is gemount en wat de beschikbare ruimte is.

5. Regel het mounten bij boot

echo "UUID=$(sudo blkid -s UUID -o value /dev/sdb1) /mnt/data ext4 defaults,noatime 0 2" | sudo tee -a /etc/fstab

Dit voegt een regel toe aan `/etc/fstab`, het bestand dat bepaalt welke bestandssystemen bij het opstarten worden gemount. Het gebruik van het UUID in plaats van de devicenaam is belangrijk: devicenamen zoals `/dev/sdb1` kunnen veranderen als je disks toevoegt of verwijderd, het UUID blijft gekoppeld aan het bestandssysteem zelf. De optie `noatime` voorkomt dat elke leesactie een timestamp-update schrijft — een kleine prestatie-optimalisatie die op drukke servers merkbaar kan zijn.

6. Test de fstab-configuratie sudo umount /mnt/data && sudo mount -a Met `mount -a` leest het systeem `/etc/fstab` en mount alles wat daarin staat. Als dit commando zonder foutmelding terugkomt, is je configuratie correct. Een fout in `/etc/fstab` kan ertoe leiden dat het systeem bij de volgende reboot niet meer opstart — daarom test je dit nu, en niet bij een herstart.

Verificatie

Controleer of het bestandssysteem correct functioneert:

df -h /mnt/data
sudo tune2fs -l /dev/sdb1 | grep "Filesystem features"

De eerste opdracht toont het gemounte volume met de beschikbare ruimte. De tweede toont de actieve kenmerken van het bestandssysteem — je zou onder andere `extents`, `has_journal` en `flex_bg` in de lijst moeten zien staan. Ontbreekt `has_journal`, dan draait het volume zonder journaal en ben je een crash verder van een consistent bestandssysteem.

Veelgestelde problemen

Het systeem start niet op na een fstab-wijziging Je hebt een fout gemaakt in `/etc/fstab`. Start op van een live-USB, mount de root-partitie en verwijder of corrigeer de verkeerde regel. Voorkomen is beter: draai na elke fstab-wijziging `sudo mount -a` en kijk of er foutmeldingen verschijnen.

Bestanden zijn traag te openen na een crash Het journaal is teruggespoeld en het bestandssysteem is consistent, maar de block cache is leeg. Dit is normaal en trekt binnen enkele minuten recht naarmate het systeem weer data in het geheugen laadt.

`mkfs.ext4` weigert te draaien op een partitie die als swap is gemarkeerd Je moet de swap eerst uitschakelen met `sudo swapoff /dev/sdb1`, de partitie opnieuw partitioneren zonder swap-vlag, en dan pas formatteren.

Waar ext4 wel en niet voor is

Voor de meeste workloads — een webserver, een database met een eigen backup-strategie, een file server voor een klein team — is ext4 de veilige keuze. Het is uitgebreid getest, de tooling is volwassen en de kans dat je een onverwachte tegenkomt is klein. Dat is meer dan je van de nieuwere bestandssystemen kunt zeggen, die hun stabiliteit nog moeten bewijzen op productieservers.

Heb je snapshots, compressie of checksum-controle nodig, dan moet je verder kijken. Maar weeg af of je die functies echt gebruikt, of dat je ze mooi vindt klinken in een presentatie. Een Btrfs-volume met snapshots die je nooit terugdraait, is complexer dan een ext4-volume met een simpele nightly backup — en de backup werkt ook nog eens als je disk fysiek kapotgaat.