Linux concept: filesystems

1. De basis

Een bestandssysteem is de structuur die een systeem op een opslagapparaat schrijft, zodat kale blokken bruikbaar worden als bestanden met namen in mappen. Het is tegelijk een indeling op schijf en de kernelcode die die indeling begrijpt.

Begin bij wat de hardware aanbiedt. Een schijf, een SSD, een partitie, een LVM-volume: ze geven de kernel allemaal hetzelfde eenvoudige ding, een genummerde reeks blokken van vaste grootte die je kunt lezen en schrijven. Blok 0, blok 1, blok 2, tot een paar honderd miljoen aan toe. Meer structuur is er niet. Als jij een bestand factuur.pdf wil dat van jou is, 240 KB groot is en in /home/peter/admin/ staat, dan moet elk onderdeel van die zin door iemand in die blokken worden gezet.

Het bestandssysteem is die iemand. Het bepaalt welke blokken je inhoud bevatten, schrijft een record met "dit bestand is 240 KB, eigendom van gebruiker 1000, en de inhoud staat in blok 900.112 tot 900.171", en schrijft een tweede record in de map met "de naam factuur.pdf verwijst naar dat record". Al het andere volgt uit die twee ideeën.

1.1 Wat een bestandssysteem eigenlijk is

Het helpt om te zien dat het woord op drie manieren wordt gebruikt, want Linux gebruikt ze alle drie en ze betekenen niet hetzelfde:

Als iemand zegt "het bestandssysteem is vol", bedoelt hij de tweede. Zegt iemand "controleer het bestandssysteem", dan bedoelt hij meestal ook fsck op die tweede. Zegt een programmeur "lees het van het bestandssysteem", dan bedoelt hij de derde. Die drie uit elkaar houden haalt verrassend veel verwarring uit een gesprek over opslag.

1.2 Drie dingen, geen één: data, metadata en namen

Het nuttigste idee uit dit hele artikel is dat een bestand niet één object is. Het zijn drie losse dingen die het bestandssysteem op drie losse plaatsen bewaart:

DIRECTORY ENTRY     "invoice.pdf"  →  inode 61743294       (the name)
        |
        v
INODE 61743294      size, owner, group, permissions, three
                    timestamps, link count, and a map of blocks   (the facts)
        |
        v
DATA BLOCKS         900112, 900113, 900114, ...                  (the content)

De mapvermelding is alleen een naam plus een nummer. De inode bevat elk feit over het bestand behalve de naam. De datablokken bevatten de bytes. Een map is geen doos waar bestanden in zitten; het is een kleine tabel met namen en inodenummers, en die map is zelf ook een bestand.

Het juiste mentale model: een bestandsnaam is een verwijzing, geen bestand. Het bestand is de inode plus zijn blokken. Deze ene scheiding verklaart harde links, waarom verwijderen direct klaar is, waarom een volle schijf vol kan blijven na rm, en waarom een bestand verplaatsen binnen één bestandssysteem helemaal geen tijd kost.

1.3 Eén boom, veel bestandssystemen

Windows geeft elk geformatteerd volume een eigen letter. Linux doet het omgekeerd: er is precies één boom, die begint bij /, en elk ander bestandssysteem wordt daarin geënt op een koppelpunt, wat gewoon een bestaande map is. Na het koppelen zie je nergens in een pad waar het ene bestandssysteem ophoudt en het volgende begint.

$ findmnt -o TARGET,SOURCE,FSTYPE
TARGET            SOURCE                             FSTYPE
/                 /dev/mapper/ubuntu--vg-ubuntu--lv  ext4
├─/boot           /dev/nvme0n1p2                     ext4
│ └─/boot/efi     /dev/nvme0n1p1                     vfat
├─/dev/shm        tmpfs                              tmpfs
└─/run            tmpfs                              tmpfs

Vier verschillende bestandssystemen op drie soorten opslag, en één ervan (tmpfs) staat helemaal niet op een schijf. Een gebruiker die cd /boot/efi typt, steekt twee grenzen over zonder het te merken, en dat is precies de bedoeling.

Het deel van de kernel dat dit mogelijk maakt is de VFS, het Virtual File System. Het definieert één set bewerkingen, open, read, write, rename, en elk type bestandssysteem implementeert die. Jouw programma roept open() aan en komt nooit te weten of het antwoord van ext4 kwam, van een USB-stick met FAT, van een netwerkshare of uit het geheugen. Het artikel over de kernel behandelt de VFS als een van de kerntaken van de kernel; hier is het van belang omdat het de reden is dat alle commando's hieronder op elk type bestandssysteem hetzelfde werken.

1.4 Wat er onder zit

Het bestandssysteem is één laag in een stapel, en opslagproblemen zijn veel makkelijker op te lossen als je weet naar welke laag je kijkt. Op de machine waarop dit artikel is gemaakt, is de stapel vijf lagen diep:

$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
NAME                         SIZE TYPE  FSTYPE       MOUNTPOINT
nvme0n1                      1.9T disk
├─nvme0n1p1                    1G part  vfat         /boot/efi
├─nvme0n1p2                    2G part  ext4         /boot
└─nvme0n1p3                  1.9T part  crypto_LUKS
  └─dm_crypt-0               1.9T crypt LVM2_member
    └─ubuntu--vg-ubuntu--lv  1.9T lvm   ext4         /

Lees het van onder naar boven: een ext4-bestandssysteem staat op een logisch volume, dat in een LVM-volumegroep zit, die in een versleutelde LUKS-container zit, die een partitie op een NVMe-schijf is. Elke laag ziet alleen genummerde blokken van de laag eronder en geeft genummerde blokken door aan de laag erboven.

Door die gelaagdheid zijn "de schijf is vol" en "het bestandssysteem is vol" twee verschillende zinnen, kun je een bestandssysteem vergroten zonder de schijf aan te raken, en is versleuteling onzichtbaar voor ext4. Het is ook de volgorde waarin je moet denken als er iets stukgaat: een schijffout, een LUKS-probleem, een LVM-probleem en een probleem in het bestandssysteem zien er allemaal uit als "ik kan niet bij mijn bestanden".

3. Een korte geschiedenis

Het ontwerp van bestandssystemen is gedreven door drie soorten druk, in deze volgorde: schijven überhaupt bruikbaar maken, een crash overleven, en meegroeien met schijven die veel harder groeiden dan iemand had gepland.

Unix had in 1969 het inode-idee al, en dat is in vijftig jaar nauwelijks veranderd. Wat wel veranderde waren snelheid en veiligheid. Het oorspronkelijke Unix-bestandssysteem verspreidde inodes en data over de schijf en verloor veel tijd met zoeken. In 1983 introduceerde het Berkeley Fast File System cilindergroepen, grotere blokken en het idee om de metadata van een bestand dicht bij zijn data te houden, en maakte Unix-schijven meerdere keren sneller. Vrijwel elk bestandssysteem sindsdien heeft dat idee in een of andere vorm overgenomen.

Linux begon met het Minix-bestandssysteem, dat bestandsnamen van maar 14 tekens toestond en partities van maar 64 MB. Die grens is de reden dat ext überhaupt bestaat: Remy Card schreef in 1992 het Extended File System om eraan te ontsnappen, en verving het een jaar later door ext2, dat tien jaar lang de Linux-standaard bleef.

De volgende druk was herstel na een crash. Op een groot ext2-bestandssysteem betekende een onverwachte stroomuitval een volledige fsck, en een volledige fsck op een grote schijf kon uren duren terwijl de server plat lag. Journalen loste dat op, en ext3 (2001) voegde het toe aan ext2 zonder de indeling op schijf te veranderen, zodat je ter plekke kon bijwerken. ext4 (2006, stabiel in 2008) voegde daarna extents, uitgestelde toewijzing, veel ruimere grenzen en snellere toewijzing toe, en is nog steeds de standaard in de meeste distributies.

De derde druk was schaal, en die leverde een ander soort bestandssysteem op. XFS kwam in 1994 van Silicon Graphics voor machines die video verwerkten, werd in 2000 als open source vrijgegeven, en was vanaf het begin gebouwd voor zeer grote bestanden en veel gelijktijdige schrijvers. ZFS (Sun, uitgebracht in 2005) en Btrfs (in 2007 begonnen bij Oracle, vanaf 2009 in de hoofdkernel) gingen verder en trokken de volumebeheerder in het bestandssysteem, met checksums op alles, snapshots en copy-on-write.

Eén licentiedetail verklaart een praktisch ongemak. ZFS is uitstekend en mag niet in de Linux-kernel worden meegeleverd, omdat de CDDL-licentie ervan en de GPL van de kernel als onverenigbaar worden gezien. Daarom komt ZFS op Linux als een losse module die je installeert en bij elke kernel opnieuw bouwt, terwijl Btrfs, dat op dezelfde doelen mikt, er gewoon is.

5. Gematigde toepassingen: inodes, namen en blokken

Dit hoofdstuk neemt het model met drie delen uit hoofdstuk 1.2 en laat elk deel op een echt systeem zien. Alles hier werkt op ext4 en heeft geen root nodig.

5.1 Een inode lezen met stat

ls -l geeft een gepolijste samenvatting. stat laat de inode bijna rauw zien, en dat is het gereedschap waar je naar grijpt zodra een bestand zich vreemd gedraagt:

$ printf 'x' > tiny.txt        # a file containing exactly one byte

$ stat tiny.txt
  File: tiny.txt
  Size: 1          Blocks: 8          IO Block: 4096   regular file
Device: 252,1      Inode: 61743294    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/   pe7er)   Gid: ( 1000/   pe7er)
Access: 2026-09-06 22:14:03.840817742 +0200
Modify: 2026-09-06 22:14:03.840817742 +0200
Change: 2026-09-06 22:14:03.840817742 +0200
 Birth: 2026-09-06 22:14:03.840817742 +0200

Lees dat veld voor veld, want elke regel is een feit dat het bestandssysteem ergens heeft moeten opschrijven:

Let op wat er niet staat: de bestandsnaam komt alleen op de eerste regel voor, en alleen omdat jij hem intypte. De inode zelf weet niet hoe hij heet.

5.2 Een naam is geen bestand

Geef dezelfde inode een tweede naam en beide namen zijn even echt. Geen van beide is het origineel:

$ ln tiny.txt hard.txt          # a hard link: a second name, same inode

$ stat -c '%n inode=%i links=%h' tiny.txt hard.txt
tiny.txt inode=61743294 links=2
hard.txt inode=61743294 links=2

Verwijder er één en de data blijft bestaan, want rm verwijdert geen bestanden. Het haalt een naam weg en verlaagt de linkteller; het bestandssysteem geeft de blokken pas vrij als die teller nul wordt en niemand het bestand meer open heeft. Dat is het hele mechanisme achter de schijf die vol blijft nadat je een logbestand hebt verwijderd, en het artikel over du volgt dat in detail.

Een symbolische link is iets heel anders: een eigen inode, met een pad als tekst erin.

$ ln -s tiny.txt soft.txt

$ stat -c '%n inode=%i size=%s type=%F' soft.txt
soft.txt inode=61743295 size=8 type=symbolic link

De grootte is 8 bytes, precies de lengte van de tekst tiny.txt. Meer is een symbolische link niet: een klein bestand waarvan de inhoud een pad is, dat bij elk gebruik opnieuw wordt opgezocht. Hij mag naar een ander bestandssysteem wijzen en naar dingen die niet bestaan; een harde link kan geen van beide, omdat een inodenummer buiten zijn eigen bestandssysteem niets betekent.

5.3 De metadata die niet in de inode staat

De inode heeft een vast aantal velden, en veertig jaar lang was dat alle metadata die een bestand kon hebben. Moderne bestandssystemen voegen een tweede, open opslag toe: uitgebreide attributen, willekeurige paren van naam en waarde die aan een bestand hangen. Dat zijn de functie ext_attr en de koppeloptie user_xattr die je terugziet in de uitvoer van dumpe2fs in hoofdstuk 6.1.

De gebruikelijke gereedschappen zijn setfattr en getfattr uit het pakket attr, dat veel distributies niet standaard installeren. De systeemaanroepen zijn er altijd, dus alles kan ze gebruiken:

$ python3 -c "
import os
os.setxattr('tiny.txt', 'user.author', b'Peter Martin')
print(os.listxattr('tiny.txt'), os.getxattr('tiny.txt', 'user.author'))
"
['user.author'] b'Peter Martin'

Attribuutnamen zitten in vier naamruimtes, en het voorvoegsel bepaalt wie ze mag schrijven:

Toegangscontrolelijsten (ACL's) blijken dan een gebruiker van datzelfde mechanisme te zijn en geen losse functie. De klassieke bits voor eigenaar, groep en anderen kunnen "en deze ene extra gebruiker mag schrijven" niet uitdrukken, dus ACL's voegen vermeldingen per gebruiker en per groep toe. Ze worden aangezet met de koppeloptie acl, die op ext4 standaard aanstaat:

$ setfacl -m u:root:rw tiny.txt      # give one named user write access

$ ls -l tiny.txt
-rw-rw-r--+ 2 pe7er pe7er 1 Sep  6 22:14 tiny.txt      # note the trailing +

$ getfacl -c tiny.txt
user::rw-
user:root:rw-                       # the extra entry
group::rw-
mask::rw-
other::r--

Die + achter de rechten is de enige hint die ls je geeft, en je kijkt er makkelijk overheen terwijl je je afvraagt waarom een gebruiker kan schrijven in een bestand dat dat lijkt te verbieden. Waar staat de ACL? In een uitgebreid attribuut:

$ python3 -c "import os; print(os.listxattr('tiny.txt'))"
['user.author', 'system.posix_acl_access']

Twee praktische gevolgen. De vermelding mask is een bovengrens voor elke benoemde vermelding, en chmod op een bestand met een ACL verandert het masker in plaats van de vermeldingen, waardoor rechten uit zichzelf lijken terug te springen. En uitgebreide attributen worden standaard niet meegekopieerd: gebruik cp -a (of --preserve=xattr), rsync -X en tar --xattrs, of je laat stilletjes ACL's, SELinux-labels en bestandscapabilities vallen terwijl je "alles" kopieert.

5.4 Waarom een bestand van één byte vier kilobyte kost

Het bestandssysteem deelt ruimte uit in hele blokken, normaal 4096 bytes, dus een bestand van één byte neemt een heel blok in en verspilt er 4095 van:

$ du -h --apparent-size tiny.txt
1       tiny.txt              # the content

$ du -h tiny.txt
4.0K    tiny.txt              # the allocation

Bij één bestand is dat een curiositeit. Op schaal is het een begrotingspost: 100.000 bestanden van 100 bytes bevatten 10 MB aan inhoud en nemen 410 MB schijf in. Mappen vol PHP-sessies, mailberichten, miniaturen of Git-objecten kosten routineus tien keer wat ze wegen.

De blokgrootte wordt gekozen als het bestandssysteem wordt aangemaakt en kan daarna niet worden veranderd zonder opnieuw te formatteren. Op Linux is hij feitelijk altijd 4096, want dat is de paginagrootte van het geheugen, en een blok groter dan een pagina is nooit eenvoudig te ondersteunen geweest.

5.5 Inodes op terwijl df zegt dat er ruimte is

Omdat ext4 het aantal inodes vastlegt bij het aanmaken, kun je door je bestanden heen raken terwijl er ruimte over is. Het aantal volgt uit één instelling in /etc/mke2fs.conf:

$ grep inode_ratio /etc/mke2fs.conf
        inode_ratio = 16384

Eén inode per 16 KB bestandssysteem. Op een volume van 2 TB zijn dat de 124,8 miljoen inodes uit hoofdstuk 4.2, ruim voldoende voor gewoon gebruik. Niet ruim voldoende voor een mailserver, en mkfs laat je dat vooraf zeggen:

$ mkfs.ext4 -T news  /dev/sdb1     # one inode per 4 KB: many small files
$ mkfs.ext4 -i 4096  /dev/sdb1     # the same thing, said directly
$ mkfs.ext4 -T largefile /dev/sdb1 # one inode per 1 MB: video, backups, images

Het verschil is niet subtiel. Hetzelfde apparaat van 512 MB krijgt, op drie manieren geformatteerd, 512, 32.768 of 131.072 inodes. Kies verkeerd richting "largefile" op een mailspool en het bestandssysteem zit vol na een paar honderd berichten terwijl df -h laat zien dat het leeg is. Kies verkeerd de andere kant op en je besteedt schijfruimte aan een inodetabel die niemand gebruikt.

Meldt een schijf "No space left on device" terwijl df -h dat tegenspreekt, controleer dan eerst de inodes en zoek daarna de map die het veroorzaakt:

$ df -i /var
$ du --inodes -d 1 /var | sort -rn | head    # count files, not bytes

XFS ontloopt dit hele probleem door inodes te maken terwijl het bezig is, en dat is een echte reden om het te kiezen voor een bestandssysteem dat een onvoorspelbaar aantal kleine bestanden gaat bevatten.

5.6 Koppelopties die ertoe doen

Opties staan in /etc/fstab en worden getoond door findmnt. Een handvol verandert het gedrag genoeg om ze bij naam te kennen:

Je kunt relatime lui zien zijn. Lees een net geschreven bestand en de toegangstijd beweegt niet, omdat die nog niet ouder is dan de wijzigingstijd:

$ findmnt -n -o OPTIONS /
rw,relatime

$ stat -c '%x' tiny.txt
2026-09-06 22:16:06.891262059 +0200
$ cat tiny.txt > /dev/null       # read it
$ stat -c '%x' tiny.txt
2026-09-06 22:16:06.891262059 +0200      # unchanged: no write happened

Dat is een bewuste tussenweg: relatime kwam in 2007 en werd twee jaar later de standaard in de kernel. Strikte atime maakte van elke leesactie een schrijfactie, wat duur en voor bijna iedereen zinloos was, terwijl relatime de toegangstijd bruikbaar genoeg houdt voor de paar gereedschappen die hem lezen.

5.7 fstab, UUID's en waarom apparaatnamen niet te vertrouwen zijn

Apparaatnamen als /dev/sda2 worden toegekend in de volgorde waarin de kernel hardware vindt. Voeg een schijf toe, verplaats een kabel, of start een virtuele machine met een andere controller, en de /dev/sdb van gisteren is de /dev/sdc van vandaag. Daarom worden bestandssystemen aangeduid met een UUID die in hun eigen superblok staat:

$ grep -v '^#' /etc/fstab
/dev/disk/by-uuid/e6894fe9-f40d-42ef-8183-6a31e0996127 /boot     ext4 defaults 0 1
/dev/disk/by-uuid/DAB0-BDC6                            /boot/efi vfat defaults 0 1

$ lsblk -f          # the same UUIDs, read from the filesystems themselves

De laatste twee cijfers op elke regel verdienen een zin. Het eerste is voor het oeroude backupgereedschap dump en is altijd 0. Het tweede is de fsck-volgorde bij het opstarten: 1 voor het rootbestandssysteem, 2 voor de rest, 0 voor "nooit controleren". Zet het op 0 voor een bestandssysteem dat er bij het opstarten misschien niet is, of voor een bestandssysteem, zoals een netwerkkoppeling, waar een controle bij het opstarten geen zin heeft.

Eén waarschuwing die mensen veel tijd kost: een kapotte regel in fstab laat het opstarten vastlopen. Test een nieuwe regel met mount -a terwijl het systeem draait, en start pas daarna opnieuw op.

7. Iets wat de meeste gebruikers niet weten

7.1 Bestandsnamen zijn bytes, geen tekst

Linux bewaart bestandsnamen niet als tekst. Het bewaart een reeks bytes, en het handhaaft precies twee regels: de reeks mag geen schuine streep bevatten, want die scheidt padonderdelen, en geen nulbyte, want die beëindigt de tekst. Al het andere mag:

$ touch $'bad\xffname'          # 0xff is not valid UTF-8 at all
$ touch $'two\nlines'           # a newline inside the name

$ ls -b
bad\377name
two\nlines

Beide bestanden bestaan en gedragen zich normaal. De kernel heeft nooit gecontroleerd of die bytes iets spellen; dat is het werk van je terminal, en met ls -b (kort voor "escape") zie je wat er echt staat.

Dit is geen curiositeit maar de reden achter een hele familie scriptgewoontes. Een bestandsnaam kan een regeleinde bevatten, dus for f in $(ls) is per constructie kapot; een bestandsnaam kan met een streepje beginnen, dus rm * kan van een bestand een vlag maken; een bestandsnaam kan ongeldige UTF-8 bevatten, dus een script dat leesbare tekst verwacht klapt erop. Daarom bestaan find -print0 en xargs -0, en daarom zetten zorgvuldige scripts elke variabele tussen aanhalingstekens.

7.2 De grens van 255 is in bytes, dus accenten kosten dubbel

De Namelen: 255 uit hoofdstuk 4.1 telt bytes, geen tekens. In pure ASCII is dat hetzelfde, en passen er precies 255 tekens in:

$ touch $(printf 'a%.0s' {1..255})     # 255 bytes: fine
$ touch $(printf 'a%.0s' {1..256})
touch: cannot touch 'aaaa...aaa': File name too long

Gebruik nu een letter die UTF-8 in twee bytes bewaart, zoals een e met een accent aigu, en de grens komt op de helft:

$ touch $(printf '\xc3\xa9%.0s' {1..127})   # 127 letters, 254 bytes: fine
$ touch $(printf '\xc3\xa9%.0s' {1..128})   # 128 letters, 256 bytes
touch: cannot touch '...': File name too long

Een Nederlandse, Franse of Duitse bestandsnaam kan dus bij 128 tekens worden geweigerd terwijl een Engelse van 255 wordt geaccepteerd, en van een emoji, vier bytes per stuk, passen er 63. Dezelfde rekensom geldt voor de padgrens van 4096 bytes, en daar lopen diep geneste mappen met lange vertaalde namen af en toe tegen een muur aan die op een fout in de toepassing lijkt.

7.3 Een nieuw bestandssysteem mist al ruimte

Formatteer een apparaat en een merkbaar deel is weg voordat je één bestand schrijft. De testimage van 512 MB uit hoofdstuk 6.1 zegt het onomwonden:

Block count:              131072       # 131072 x 4096 = 512 MiB
Free blocks:              124719       # 6353 blocks gone already = 24.8 MiB
Reserved block count:       6553       # another 25.6 MiB you cannot use
Inode count:              32768        # x 256 bytes each = 8 MiB of inode table
Total journal size:         16M        # the journal, before any data

De rekensom klopt bijna precies: 8 MiB inodetabel plus een journal van 16 MiB plus groepsboekhouding is de 24,8 MiB die verdween. Daarbovenop is 5% gereserveerd voor root, dus ongeveer 10% van een vers bestandssysteem is al vergeven.

Schaal dat naar het bestandssysteem van 2 TB uit hoofdstuk 4.2 en de getallen zijn niet schattig meer. De 124.829.696 inodes van 256 bytes per stuk zijn 29,8 GiB inodetabel, geschreven tijdens mkfs en permanent. De rootreserve van 5% is nog eens 95 GiB, en dat is het gat tussen Free en Available in de uitvoer van stat -f. Die reserve is geen verspilling: hij houdt root in staat om in te loggen en syslog in staat om te schrijven als de schijf volloopt, precies wanneer je allebei nodig hebt. Op een puur datavolume, waar niets van die veiligheidsmarge afhangt, kun je het meeste ervan terugnemen:

$ sudo tune2fs -m 1 /dev/sdb1     # reduce the root reserve from 5% to 1%

Doe dat op een dataschijf. Doe het niet op het rootbestandssysteem.

7.4 FAT rondt elke tijdstempel af op twee seconden

De FAT-indeling bewaart een wijzigingstijd in 16 bits, en besteedt daarvan maar vijf aan seconden, dus telt hij in stappen van twee. Je kunt het bewijzen zonder USB-stick, met een image en het pakket mtools, dat FAT leest zonder te koppelen:

$ truncate -s 64M fat.img && mkfs.vfat -F 32 -n TESTFAT fat.img
$ for s in 01 02 03; do
>   touch -d "2026-01-01 10:00:$s" t$s.txt
>   mcopy -m -o -i fat.img t$s.txt ::/      # -m preserves the timestamp
> done

Lees nu het rauwe tijdveld van 16 bits uit elke mapvermelding, op positie 22, en decodeer het:

$ python3 -c "
d = open('fat.img','rb').read()
for n in (b'T01     TXT', b'T02     TXT', b'T03     TXT'):
    i = d.find(n); t = int.from_bytes(d[i+22:i+24], 'little')
    print(n.decode(), '%02d:%02d:%02d' % (t>>11, (t>>5)&63, (t&31)*2))
"
T01     TXT 10:00:00      # 10:00:01 rounded down
T02     TXT 10:00:02
T03     TXT 10:00:02      # 10:00:03 rounded down too

Drie bestanden met een seconde ertussen, twee verschillende tijdstempels. Daarom meldt een backup- of synchronisatieprogramma dat wijzigingstijden vergelijkt op een FAT-stick dat bestanden veranderd zijn terwijl er niets veranderde, en daarom heeft rsync een optie --modify-window=1 die bijna alleen hiervoor bestaat.

Dezelfde mapvermelding toont het andere FAT-compromis. Elke lange naam wordt twee keer bewaard, als klassieke 8.3-naam plus verborgen extra vermeldingen met de echte naam:

$ mdir -i fat.img ::/
MYLONG~1 TXT         6 2026-09-06  22:16  MyLongFileName.txt
tiny     txt         1 2026-09-06  22:16

En omdat FAT namen hoofdletterongevoelig vergelijkt, zijn MyLongFileName.txt en mylongfilename.TXT daar hetzelfde bestand en op ext4 twee verschillende. Kopieer een map van Linux naar een USB-stick en bestanden kunnen elkaar alleen daardoor stilletjes overschrijven.

7.5 Je bestandssysteem telt elke byte die er ooit in geschreven is

ext4 houdt in zijn superblok een teller bij van alles wat er ooit in is geschreven en toont die via /sys, zonder root:

$ cat /sys/fs/ext4/dm-1/lifetime_write_kbytes
19500766413                        # about 18.2 TiB since this disk was formatted

$ cat /sys/fs/ext4/dm-1/session_write_kbytes
6183360                            # about 5.9 GiB since the last mount

Dat eerste getal is echt nuttig op een SSD, waar de levensduur in totaal geschreven bytes wordt opgegeven. Het is ook een stille herinnering aan hoeveel een gewone desktop schrijft: achttien terabyte door een bestandssysteem waarvan de eigenaar nooit bewust meer dan een paar honderd gigabyte heeft weggeschreven.

Dezelfde map bevat de rest van de levende knoppen en tellers van ext4, en /sys/fs/ext4/features/ laat zien wat het ext4-stuurprogramma van jouw kernel kan, en dat is niet hetzelfde als waarmee jouw bestandssysteem is aangemaakt.

7.6 ext4 kan hoofdletterongevoelig zijn, en ext3 raakt in 2038 door de tijd heen

Twee functies die tegenspreken wat de meeste mensen over ext4 aannemen.

De eerste is casefolding. Sinds Linux 5.2 kan ext4 namen per map hoofdletterongevoelig vergelijken, wat vooral bestaat zodat Wine en Android software kunnen draaien die Windows-gedrag verwacht. Het staat uit tenzij het bestandssysteem ermee is aangemaakt:

$ mkfs.ext4 -q -F -O casefold cf.img
$ dumpe2fs -h cf.img | grep features
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent
                     64bit flex_bg casefold sparse_super large_file huge_file ...

De tweede is het jaar 2038-probleem. Een tijdstempel van 32 bits met teken die seconden vanaf 1970 telt, loopt op 19 januari 2038 over. ext4 ontsnapte eraan met inodes van 256 bytes met extra bits voor de tijd, die de grens naar het jaar 2446 duwen:

$ touch -d '2100-06-01 12:00:00' future.txt
$ stat -c '%y' future.txt
2100-06-01 12:00:00.000000000 +0200        # accepted without complaint

Een oud ext3-bestandssysteem, of een ext4 dat lang geleden met inodes van 128 bytes is aangemaakt, heeft geen ruimte voor die bits en stopt in 2038. De inodegrootte ligt vast bij het aanmaken en kan niet worden veranderd, dus de enige oplossing is het bestandssysteem opnieuw maken. Het is de moeite waard om de regel Inode size in dumpe2fs te bekijken op elke server waarvan de schijven meer dan tien jaar geleden zijn geformatteerd.

7.7 Je SSD hoort misschien nooit wat je hebt verwijderd

Een SSD kan een blok niet overschrijven; hij kan alleen een groot gebied wissen en opnieuw schrijven. De controller moet dus weten welke blokken niets nuttigs meer bevatten, anders besteedt hij zijn leven aan het zorgvuldig bewaren van data die maanden geleden is verwijderd. TRIM, ook discard genoemd, is het bestandssysteem dat tegen het apparaat zegt: "deze blokken zijn nu vrij".

Of dat bericht aankomt is een andere vraag, en het antwoord verschilt per laag. lsblk -D toont de discard-grenzen van elke laag in de stapel, en op deze machine breekt de ketting:

$ lsblk -D -o NAME,DISC-GRAN,DISC-MAX,MOUNTPOINTS -e7
NAME                        DISC-GRAN DISC-MAX MOUNTPOINTS
nvme0n1                          512B       2T
├─nvme0n1p1                      512B       2T /boot/efi
├─nvme0n1p2                      512B       2T /boot
└─nvme0n1p3                      512B       2T
  └─dm_crypt-0                   512B       0B
    └─ubuntu--vg-ubuntu--lv      512B       0B /

De schijf en zijn partities accepteren discards tot 2 TB. De LUKS-laag erboven meldt 0B, en het logische volume daarboven ook. Het rootbestandssysteem op deze laptop heeft nog nooit iets getrimd, en zal dat ook niet doen zolang de stapel er zo uitziet, want LUKS gooit discard-verzoeken weg tenzij het wordt geopend met --allow-discards.

Die standaard is bewust gekozen en geen vergissing. Discards door versleuteling heen laten vertelt iedereen die het rauwe apparaat kan lezen welke blokken ongebruikt zijn, en dat verraadt de vorm van het bestandssysteem en hoe vol het zit, precies wat een versleuteld volume geheim hoort te houden. De afweging is echt: laat discards door en de SSD blijft snel, of houd ze tegen en geef een stukje op van waar versleuteling voor was.

Waar discards wel doorkomen, kies de wekelijkse batch boven de koppeloptie: fstrim loopt de vrije ruimte één keer af, terwijl discard bij elke verwijdering een opdracht stuurt en op sommige hardware kan haperen.

$ systemctl is-enabled fstrim.timer
enabled

$ sudo fstrim -av                 # trim every mounted filesystem that supports it

Nog iets wat dit duidelijk maakt: het bestandssysteem bepaalt niet waar je data fysiek terechtkomt. De vertaallaag van de SSD zelf doet de plaatsing, de slijtageverdeling en het opruimen, en vertelt het bestandssysteem daar niets over. Elk bloknummer uit hoofdstuk 6.2 is een verzinsel dat het apparaat voor jouw gemak in stand houdt.

7.8 Oversteken naar Windows en macOS

De meeste Linux-servers worden beheerd vanaf een Mac of een Windows-laptop, en bestanden gaan de hele dag heen en weer tussen die drie. Je hoeft niet te weten hoe NTFS of APFS vanbinnen werken om dat veilig te doen, maar je moet wel weten waar ze het oneens zijn met Linux, want elk meningsverschil levert een fout op die op iets heel anders lijkt.

Hoofdletters zijn de eerste. Linux vergelijkt bestandsnamen byte voor byte, dus Logo.png en logo.png zijn twee verschillende bestanden. NTFS en APFS zijn standaard hoofdletterongevoelig, dus op een laptop zijn het er één. Een webpagina die om logo.png vraagt terwijl de repository Logo.png bevat, werkt daarom perfect op de machine van de ontwikkelaar en geeft een 404 op de server, en niets op die laptop zal er ooit voor waarschuwen. Hoofdstuk 7.4 liet dezelfde botsing zien op een FAT-stick; dit is de versie die de productieomgeving haalt.

Unicode-normalisatie is de tweede, en die is gemener omdat je hem niet kunt zien. De letter e met een accent aigu kan worden opgeslagen als één teken, of als een gewone e gevolgd door een combinerend accent. macOS normaliseert bestandsnamen zodat beide schrijfwijzen bij hetzelfde bestand uitkomen. Linux bewaart precies de bytes die het kreeg:

$ printf 'nfc' > "$(printf 'caf\xc3\xa9')"     # e-acute as one character
$ printf 'nfd' > "$(printf 'cafe\xcc\x81')"    # plain e plus a combining accent

$ ls -1 | grep caf | while IFS= read -r f; do
>   printf '%s  %s  %s\n' "$f" "$(printf '%s' "$f" | xxd -p)" "$(cat -- "$f")"
> done
café  63616665cc81  nfd
café  636166c3a9    nfc

Twee bestanden, één map, op het scherm identiek, andere bytes. Kopieer een boom van een Mac naar een Linux-server en een bestandsnaam die je op de server intypt kan niet overeenkomen met de naam die is aangekomen, met de melding "no such file" voor een bestand waar je recht naar kijkt. Het is ook de reden dat git status in zo'n boom hetzelfde bestand soms tegelijk als verwijderd en als onbekend meldt.

Toegestane namen zijn de derde. Linux verbiedt precies twee dingen in een bestandsnaam: de schuine streep en de nulbyte. Windows verbiedt een stuk meer, en Linux maakt ze allemaal met alle plezier aan:

$ touch 'CON' 'aux.txt' 'a:b.txt' 'what?.txt' 'trailing.' 'space '
$ ls -b
a:b.txt
aux.txt
CON
space\ 
trailing.
what?.txt

Alle zes zijn hier gewone bestanden en geen van zes kan op Windows bestaan. De tekens < > : " / \ | ? * zijn daar verboden, net als stuurtekens, een punt aan het eind en een spatie aan het eind, en ook de oude apparaatnamen CON, PRN, AUX, NUL, COM1 tot COM9 en LPT1 tot LPT9, met of zonder extensie. Een backup-tar van een Linux-server kan daarom weigeren uit te pakken op een Windows-machine, en het bestand dat het tegenhoudt is meestal een log of een export met een dubbele punt in een tijdstempel.

En metadata overleeft de oversteek meestal helemaal niet. Eigenaar, rechtenbits, symbolische links en de uitgebreide attributen uit hoofdstuk 5.3 hebben op FAT of exFAT geen plek om te wonen, en wat ls -l op zo'n volume toont is verzonnen door de koppelopties. macOS werkt daaromheen door zijn eigen metadata in begeleidende bestanden te schrijven, en daarom staat een USB-stick die bij een Mac is geweest vol met ._bestandsnaam-vermeldingen en .DS_Store-bestanden die voor Linux niets betekenen.

Tot slot: wat Linux echt kan lezen. Drie van de vier vreemde bestandssystemen hebben een stuurprogramma in de hoofdkernel, en het ontbrekende is degene waar mensen het meest naar vragen:

$ for m in ntfs3 exfat hfsplus apfs; do printf '%-8s ' $m; modinfo -F filename $m 2>/dev/null || echo "(no module)"; done
ntfs3    /lib/modules/6.11.0-29-generic/kernel/fs/ntfs3/ntfs3.ko.zst
exfat    /lib/modules/6.11.0-29-generic/kernel/fs/exfat/exfat.ko.zst
hfsplus  /lib/modules/6.11.0-29-generic/kernel/fs/hfsplus/hfsplus.ko.zst
apfs     (no module)

Dat alles levert één saaie regel op die elk probleem uit dit hoofdstuk in één keer wegneemt: gebruik voor alles wat tussen de drie heen en weer gaat namen in ASCII-kleine letters, zonder spaties, zonder dubbele punten en zonder punt aan het eind. Het lijkt bijgeloof tot de dag dat een uitrol struikelt over een hoofdletter.

7.9 Het bestandssysteem in je broekzak

Dit is het feit dat het hele onderwerp opnieuw ordent: Android is Linux. Niet Linux-achtig, niet op Linux geïnspireerd. Een telefoon draait dezelfde kernel, dezelfde VFS, dezelfde inodes, dezelfde extents en dezelfde page cache als in elk hoofdstuk hierboven, meestal op ext4 of F2FS. De userspace erboven is die van Android in plaats van GNU, maar de bestandssysteemlaag is degene die dit artikel uit elkaar haalt. Begrijp je de opslag van een Linux-server, dan begrijp je al ruwweg negentig procent van die van een telefoon.

De verschillen zijn die andere tien procent waard, en ze beginnen bij de flashchip. Een telefoon bewaart data in eMMC- of UFS-geheugen, dat een blok niet kan overschrijven en in grote gebieden wist, precies zoals de SSD uit hoofdstuk 7.7, en dat verstopt achter een vertaallaag op dezelfde manier. F2FS is het bestandssysteem dat daarvoor is geschreven: het is log-gestructureerd, wat betekent dat het wijzigingen niet over het apparaat verspreidt maar achter elkaar toevoegt in grote segmenten en oude segmenten op de achtergrond opruimt. Dat patroon is waar flashhardware het snelst in is, en daarom is een bestandssysteem dat Samsung in 2012 voor telefoons ontwierp nu gebruikelijk op de datapartitie van Android-toestellen, terwijl ext4 elders op diezelfde telefoon wijdverbreid blijft.

Je hebt geen telefoon nodig om het tegen te komen. Het stuurprogramma staat op je laptop:

$ modinfo -F filename f2fs
/lib/modules/6.11.0-29-generic/kernel/fs/f2fs/f2fs.ko.zst

En het verkeer gaat ook de andere kant op. Hoofdstuk 7.5 wees naar /sys/fs/ext4/features/ zonder te zeggen wat daarin staat. Kijk naar drie van de vermeldingen:

$ ls /sys/fs/ext4/features/ | grep -E 'casefold|encryption|verity'
casefold
encrypted_casefold
encryption
test_dummy_encryption_v2
verity

Alle drie bestaan grotendeels dankzij Android, en ze zitten in het ext4-stuurprogramma van een doodgewone Ubuntu-laptop:

Drie andere verschillen bepalen hoe een telefoon aanvoelt vergeleken met een server, en elk ervan is een laag boven op de bestandssystemen uit dit artikel in plaats van een nieuw soort bestandssysteem:

• /sdcard is geen SD-kaart. Op een moderne telefoon is het geëmuleerde opslag die in de datapartitie leeft en via FUSE aan apps wordt gepresenteerd, het mechanisme uit hoofdstuk 4.4. In die omweg zit het filteren van rechten per app, en daardoor is bestandstoegang op Android trager dan het onderliggende bestandssysteem zelf.
• De systeempartitie is alleen-lezen en geverifieerd. Android koppelt die via dm-verity, een device-mapper-doel dat elk blok tijdens het lezen controleert tegen een ondertekende hashboom. Het is dezelfde device-mapper-laag die LUKS en LVM draagt in de stapel uit hoofdstuk 1.4, hier gebruikt voor integriteit in plaats van versleuteling.
• Elke app is een Unix-gebruiker. Android geeft elke geïnstalleerde toepassing een eigen UID en vertrouwt op gewone POSIX-bestandsrechten om appgegevens privé te houden. De rechtenbits uit hoofdstuk 5.1 doen het werk; de telefoon laat ze je alleen nooit zien.

Apple ging de andere kant op. iPhones en iPads draaien sinds iOS 10.3 in 2017 op APFS, hetzelfde bestandssysteem als de Macs uit hoofdstuk 7.8, met dezelfde copy-on-write-klonen en snapshots uit hoofdstuk 6.7. Het verschil is dat iOS de gebruiker helemaal geen bestandssysteem toont: er is geen pad om in te typen, en de Bestanden-app is een samengestelde weergave in plaats van een venster op een boom.

De eerlijke samenvatting van mobiele opslag is dus dat het verschil veel kleiner is dan de marketing doet vermoeden. Van de twee grote telefoonplatforms draait het ene de bestandssystemen uit dit artikel op hardware die zich gedraagt als een kleine SSD, en heeft het drie functies teruggeduwd in het ext4-stuurprogramma op je bureaublad. Het andere draait het bestandssysteem uit het Mac-hoofdstuk en verstopt het gewoon.

7.10 Weten waar het bestandssysteem ophoudt

Die laatste regel slaan mensen over. Meldt een bestandssysteem fouten, dan zit de oorzaak vaak in een laag eronder, en smartctl -a /dev/nvme0n1 beantwoordt een vraag die geen bestandssysteemgereedschap kan beantwoorden.

9. Veelgemaakte fouten

9.1 Mythe versus werkelijkheid

9.2 Andere valkuilen

• Bestanden kopiëren naar een koppelpunt dat niet gekoppeld is. Het schrijven lukt, in de onderliggende map, waarna het echte bestandssysteem eroverheen koppelt en de data uit beeld verdwijnt terwijl hij nog steeds ruimte inneemt. Controleer met findmnt voordat je schrijft.
• Formatteren met de standaard inodeverhouding voor een mail- of cachevolume. De inodes zijn op na een paar miljoen bestanden en kunnen er achteraf niet bij.
• Een sparse schijfimage kopiëren zonder --sparse=always. De gaten worden echte nullen en een kleine image wordt een image op volle grootte.
• Aannemen dat een FAT-stick eigenaar en rechten bewaart. Hij bewaart geen van beide. Wat ls -l daar toont komt uit de koppelopties uid, gid, fmask en dmask, niet van de schijf.
• Het bestandssysteem vergroten zonder het volume eronder te vergroten. De volgorde is altijd: eerst de partitie of het logische volume uitbreiden, dan pas resize2fs of xfs_growfs.
• e2fsck "even ter controle" draaien op een gekoppeld rootbestandssysteem. Het kan een bestandssysteem vernietigen waar niets mis mee was.
• du vertrouwen op een volume met snapshots of deduplicatie. Het loopt namen af, en snapshots hebben er geen. Gebruik btrfs filesystem usage of zfs list -o space.
• Een database of VM-image zonder nadenken op een copy-on-write-bestandssysteem zetten. Willekeurige herschrijvingen in een CoW-bestand fragmenteren zwaar; gebruik chattr +C op de map, of een subvolume met CoW uit.
• Een repository uitrollen die op een hoofdletterongevoelige laptop is gebouwd. Logo.png en logo.png zijn één bestand op macOS en Windows en twee op Linux, dus de 404 verschijnt pas in productie. Herstel de hoofdletters in de repository, niet op de server.
• Aannemen dat je een Mac-schijf even kunt aansluiten en uitlezen. APFS heeft geen stuurprogramma in de Linux-kernel. Plan een kopie over het netwerk in plaats van daar met de schijf in je hand achter te komen.
• De + in ls -l missen. Die betekent dat een ACL toegang geeft die de rechtenbits niet tonen. Draai getfacl voordat je concludeert dat de rechten kapot zijn.
• Een bestandssysteem twee keer benchmarken en het tweede getal geloven. De page cache en de dentry cache maken elke herhaling sneller. Vergelijk koud met koud, of vergelijk niet.
• Besluiten dat een bestand weg is omdat ls niets toont. Een streepje vooraan, een spatie achteraan of een regeleinde in de naam komt vaak genoeg voor om eerst ls -b te draaien voordat je in paniek raakt.