Et filsystem gjør et flatt array av diskblokker om til et hierarki av filer og kataloger, og forvalter metadata og ledig plass for å gjøre det pålitelig og raskt.
I UNIX-filsystemer er hver fil en (index node) — en struktur som holder filens (størrelse, eier, rettigheter, tidsstempler, link count) og . Merk hva en inode lagrer: . Navn ligger i , som bare er filer som 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)──▶ ...
└──────────────┘
Dette er grunnen til at en hard link bare er en andre katalogoppføring som peker på samme inode (link count 2), og hvorfor rm egentlig er unlink — den fjerner et navn og frigjør inoden bare når link count når null.
En enkelt logisk operasjon (f.eks. en append) berører flere blokker — inoden, bitmapet over ledig plass, dataene. Et krasj midtveis etterlater filsystemet inkonsistent. En journal skriver først de tiltenkte endringene til en logg, og bruker dem så; etter et krasj spiller filsystemet av (eller forkaster) journalen i stedet for en treg full skanning (fsck). Modusene bytter sikkerhet mot hastighet: journalfør bare metadata (raskt, vanlig) kontra metadata og data.
Kernelen cacher fildata i RAM i page cache, så gjenlesninger treffer minnet og skrivinger 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 raskt, men "skrevne" data er ikke varige før fsync; databaser bruker ofte direct I/O pluss sin egen buffer pool for å styre caching og varighet presist.
Filsystemets interne mekanismer forklarer daglig oppførsel: hvorfor hard links fungerer, hvorfor det å slette en fil som en prosess fortsatt holder åpen ikke frigjør plass før den lukkes, hvorfor fsync er vesentlig for varighet (og en klassisk datatapsfeil når den utelates), og hvorfor den andre lesningen av en fil er øyeblikkelig (page cache). Senioringeniører resonnerer om disse når de velger buffered vs direct I/O for en database, dimensjonerer RAM for cache, eller feilsøker et problem med crash-consistency.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner