Filesystemcontrole (fsck): wanneer en hoe je die uitvoert

Wat fsck precies controleert

Een bestandssysteem houdt zijn eigen interne boekhouding bij: welke blocks bij welk bestand horen, welke blocks vrij zijn, directory-items, en diverse tellers en vlaggen die de staat van het bestandssysteem zelf beschrijven. Onder normale omstandigheden blijft die boekhouding consistent. Ze kan uit balans raken na een onverwachte afsluiting (stroomuitval of een harde reset die schrijfacties halverwege onderbreekt), na bepaalde soorten hardwarestoringen, of af en toe na een kernelbug. fsck (filesystem check) loopt die boekhouding door, zoekt naar inconsistenties en herstelt ze waar het zeker is van de juiste oplossing.

fsck zelf is eigenlijk een front-end. Het kijkt naar het bestandssysteemtype op het doelapparaat en geeft de controle door aan de specifieke checker voor dat type, bijvoorbeeld e2fsck voor ext2/ext3/ext4. Je kunt e2fsck ook direct aanroepen als je meer controle wilt over ext4-specifieke opties dan de generieke fsck front-end biedt, maar voor routinematig gebruik is fsck eenvoudiger, omdat het zelf uitzoekt welke checker het moet draaien.

Waarom het niet-gemount moet draaien

Een gemount, actief gebruikt bestandssysteem blijft onder je handen veranderen: bestanden worden geschreven en verwijderd, en metadata wordt bijgewerkt zolang de normale systeemactiviteit doorgaat. Een consistentiecontrole uitvoeren tegen een bewegend doel betekent dat fsck structuren die halverwege een update zitten verkeerd kan lezen, en in het slechtste geval botsen de eigen reparatieacties van fsck met een actieve schrijfactie en ontstaat er meer schade dan de oorspronkelijke inconsistentie. Daarom is fsck bedoeld om te draaien tegen een bestandssysteem dat niet gemount is, of dat strikt alleen-lezen gemount is.

Voor het rootbestandssysteem van een server is dat lastig: je kunt het bestandssysteem dat het draaiende besturingssysteem gebruikt niet zomaar unmounten. Dit is precies waarvoor rescue mode bedoeld is. Door op te starten in een aparte, minimale omgeving is de schijf die je wilt controleren nergens door in gebruik, zodat fsck er van buitenaf schoon tegenaan kan.

Basisgebruik

Richt fsck op het apparaatpad van de partitie, niet op een mount point:

fsck /dev/sdb1

Zonder opties uitgevoerd, controleert fsck het bestandssysteem en vraagt het je bij elke inconsistentie interactief om bevestiging voordat het een reparatie doorvoert. Dat is handig als je precies wilt zien wat er wordt voorgesteld. Als je al weet dat je elke voorgestelde reparatie wilt laten toepassen zonder telkens gevraagd te worden, voeg dan -y toe om automatisch met ja te antwoorden:

fsck -y /dev/sdb1

Gebruik -y weloverwogen. Bij een bestandssysteem met structurele schade kan het automatisch accepteren van elke reparatie soms betekenen dat data in lost+found terechtkomt in plaats van precies op de oorspronkelijke plek, over het algemeen nog steeds beter dan bekende corruptie laten staan, maar goed om te weten voordat je het onbeheerd laat draaien.

De exitcode lezen

De exitcode van fsck is een bitmask, geen simpele geslaagd/mislukt-vlag: er kunnen meerdere situaties tegelijk worden aangegeven doordat de waardes bij elkaar worden opgeteld. Op hoofdlijnen:

Zie deze tabel als een globale richtlijn, niet als het laatste woord. De exacte betekenis van elke bit staat in de manual page van fsck zelf (man fsck), en het is de moeite waard om die direct te raadplegen in plaats van te gokken wanneer een geautomatiseerd script of monitoringcheck op een specifieke code moet reageren.

Voordat je het uitvoert

Vermoed je dat de onderliggende schijf zelf defect raakt, en niet alleen het bestandssysteem erop, controleer dan eerst de gezondheid van de schijf, zie Een defecte schijf herkennen in Linux. Herhaalde bestandssysteemreparaties tegen een fysiek defecte schijf leveren bij de volgende controle vaak dezelfde fouten weer op. Zodra het bestandssysteem schoon wordt bevonden, mount je het zoals gebruikelijk, zie Een schijf mounten in Linux.