Ett filsystem förvandlar en platt array av diskblock till en hierarki av filer och kataloger, och hanterar metadata och ledigt utrymme för att göra det tillförlitligt och snabbt.
I UNIX-filsystem är varje fil en (index node) — en struktur som håller filens (storlek, ägare, rättigheter, tidsstämplar, link count) och . Notera vad en inode lagrar: . Namn bor i , som bara är filer som mappar namn → inode-nummer:
directory "docs" inode 1042 data blocks
┌───────────────────┐ ┌──────────────┐ ┌────────┐
│ "report.txt" →1042│───────────▶│ mode, uid │──ptr───▶│ block │
│ "notes.txt" →1050│ │ size, times │──ptr───▶│ block │
└───────────────────┘ │ link count=2 │ └────────┘
│ block ptrs │──(indirect)──▶ ...
└──────────────┘
Det är därför en hard link bara är en andra katalogpost som pekar på samma inode (link count 2), och varför rm egentligen är unlink — den tar bort ett namn och frigör inode:n först när link count når noll.
En enda logisk operation (t.ex. en append) rör flera block — inode:n, free-space-bitmappen, datan. En krasch mitt i lämnar filsystemet inkonsistent. En journal skriver först de avsedda ändringarna till en logg, och tillämpar dem sedan; efter en krasch spelar filsystemet upp (replays) (eller kasserar) journalen i stället för en långsam fullständig genomsökning (fsck). Lägen byter säkerhet mot hastighet: journalföra endast metadata (snabbt, vanligt) kontra metadata och data.
Kernel cachar fildata i RAM i page cache, så att omläsningar träffar minnet och skrivningar buffras och flushas senare (write-back):
buffered I/O (default): app ↔ page cache ↔ disk → cached, async writeback, fast re-reads
direct I/O (O_DIRECT): app ↔ disk → bypass the cache; DBs manage their own
fsync(): force buffered data to durable storage (required for real durability)
Buffrad I/O är snabb, men "skriven" data är inte durabel förrän fsync; databaser använder ofta direct I/O plus sin egen buffer pool för att kontrollera caching och durabilitet exakt.
Filsystems interna delar förklarar vardagligt beteende: varför hard links fungerar, varför att radera en fil som en process fortfarande håller öppen inte frigör utrymme förrän den stänger, varför fsync är väsentligt för durabilitet (och en klassisk dataförlust-bugg när det utelämnas), och varför den andra läsningen av en fil är omedelbar (page cache). Seniora ingenjörer resonerar om dessa när de väljer buffrad vs direct I/O för en databas, dimensionerar RAM för cache, eller felsöker ett crash-consistency-problem.
Ett bibliotek med IT-intervjufrågor och detaljerade svar — från Junior till Senior.
Donera