Et filsystem omdanner et fladt array af diskblokke til et hierarki af filer og mapper og styrer metadata og fri plads, så det bliver pålideligt og hurtigt.
I UNIX-filsystemer er hver fil en (index node) — en struktur, der holder filens (størrelse, ejer, rettigheder, tidsstempler, link count) og . Bemærk, hvad en inode gemmer: . Navne bor i , som blot er filer, der mapper navn → 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 er derfor, et hard link blot er endnu en directory entry, der peger på den samme inode (link count 2), og hvorfor rm i virkeligheden er unlink — det fjerner et navn og frigiver kun inoden, når link count når nul.
En enkelt logisk operation (fx en append) rører flere blokke — inoden, free-space-bitmap'en, dataene. Et crash midtvejs efterlader filsystemet inkonsistent. En journal skriver først de tilsigtede ændringer til en log og anvender dem derefter; efter et crash afspiller (eller kasserer) filsystemet journalen i stedet for en langsom fuld scanning (fsck). Tilstande veksler sikkerhed for hastighed: journalfør kun metadata (hurtigt, almindeligt) versus metadata og data.
Kernen cacher fildata i RAM i page cache'en, så gen-læsninger rammer hukommelsen, og skrivninger bufres og flushes senere (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)
Buffered I/O er hurtigt, men "skrevne" data er ikke holdbare (durable) før fsync; databaser bruger ofte direct I/O plus deres egen buffer pool for at styre caching og holdbarhed præcist.
Filsystemets indre forklarer hverdagsadfærd: hvorfor hard links virker, hvorfor det ikke frigiver plads at slette en fil, som en proces stadig har åben, før den lukkes, hvorfor fsync er afgørende for holdbarhed (og en klassisk data-tabs-bug, når den udelades), og hvorfor den anden læsning af en fil er øjeblikkelig (page cache). Senioringeniører ræsonnerer om disse ting, når de vælger buffered vs. direct I/O til en database, dimensionerer RAM til cache, eller debugger et crash-konsistensproblem.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér