Op een Linux-systeem zijn de naam en de inhoud van een bestand niet genoeg: je moet ook weten van wie het is, wie het mag lezen, wanneer het is gewijzigd en waar de datablokken staan. Die metadata worden opgeslagen in een inode. De manpagina inode(7) vat het zo samen: elk bestand heeft een inode met metadata, en een inodenummer dat uniek is binnen het bestandssysteem.
Wat een inode bevat
- het type (gewoon bestand, map, symbolische link, apparaat) en de toegangsrechten;
- de identificatie van de eigenaar en van de groep;
- de grootte en het aantal toegewezen blokken;
- de tijdstippen van de laatste toegang, de laatste wijziging van de inhoud en de laatste statuswijziging;
- het aantal harde links dat ernaar verwijst.
De rechten die je met chmod instelt, zoals 644 of 755, staan dus in de inode. Ook een map verbruikt een inode, zelfs als hij leeg is.
Waarom hosters inodes begrenzen
Een bestandssysteem heeft een vast of begrensd aantal inodes: zijn ze op, dan kan er geen enkel bestand meer worden aangemaakt, ook al is er nog vrije ruimte. Bij shared hosting legt de hoster daarom een quotum per account op. De blog van cPanel benadrukt het: dit quotum begrenst het aantal bestanden, niet hun grootte. Het paneel toont het vaak als "File Usage" of "Bestandsgebruik".
Het quotum heeft vaak twee drempels. Boven de zachte limiet kun je tijdens een gratieperiode nog bestanden aanmaken; bij de harde limiet wordt dat geweigerd. Met CloudLinux kun je bijvoorbeeld beide drempels voor de partitie /home instellen, met standaard een gratieperiode van zeven dagen. De waarden verschillen sterk per hoster: controleer die van je eigen pakket.
Wat inodes verbruikt op een WordPress-site
- Media: voor elke geüploade afbeelding maakt WordPress een kopie per afbeeldingsformaat dat de core, het thema en de plugins hebben geregistreerd. Een mediabibliotheek met een paar duizend foto's loopt zo al snel op tot tienduizenden bestanden.
- Caches: paginacacheplugins schrijven vaak één bestand per pagina, per apparaat of per taal; de blog van cPanel noemt caches als grote verbruikers van inodes.
- E-mail: in een mailbox die op de hosting staat, is elk bericht een bestand.
- Back-ups en vergeten bestanden: archieven die op de server zijn blijven staan, oude kopieën van de site, debuglogs. Ze vormen ook een beveiligingsprobleem, dat we beschrijven in ons artikel over blootgestelde gevoelige bestanden.
- Kapotte scripts die in een lus bestanden aanmaken, of een gehackte site vol spampagina's.
Voor WordPress
- Meet: via SSH toont
df -ide gebruikte en beschikbare inodes per bestandssysteem, enfind wp-content -type f | wc -ltelt de bestanden in een map. - Leeg caches via de betreffende plugin, in plaats van de mappen met de hand te verwijderen.
- Haal back-ups van de server: een kopie op dezelfde hosting verbruikt inodes en verdwijnt samen met die hosting. De 3-2-1-regel vraagt hoe dan ook om een kopie elders.
- Beperk overbodige afbeeldingsformaten van het thema of de plugins, en genereer daarna de miniaturen opnieuw met een geschikte tool.
- Een plotselinge, onverklaarde stijging van het aantal bestanden is een waarschuwingssignaal: controleer of er geen map volloopt met onbekende PHP- of HTML-bestanden.
Veelgemaakte fouten
Denken dat er nog ruimte is omdat de schijf niet vol is; de map van een cache verwijderen terwijl die opnieuw wordt opgebouwd; de e-mail vergeten, die het grootste deel van de bestanden van een account kan uitmaken.