Un filesystem trasforma un array piatto di blocchi disco in una gerarchia di file e directory, gestendo i metadati e lo spazio libero per renderla affidabile e veloce.
Nei filesystem UNIX, ogni file è un (index node) — una struttura che contiene i del file (dimensione, proprietario, permessi, timestamp, link count) e i . Nota cosa un inode memorizza: il . I nomi vivono nelle , che sono semplicemente file che mappano nome → numero di inode:
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)──▶ ...
└──────────────┘
È per questo che un hard link è solo una seconda voce di directory che punta allo stesso inode (link count 2), e perché rm è in realtà unlink — rimuove un nome e libera l'inode solo quando il link count arriva a zero.
Una singola operazione logica (es. un append) tocca diversi blocchi — l'inode, la bitmap dello spazio libero, i dati. Un crash a metà lascia il filesystem in uno stato incoerente. Un journal scrive prima le modifiche previste in un log, poi le applica; dopo un crash il FS riesegue (replay) o scarta il journal invece di una lenta scansione completa (fsck). Le modalità barattano sicurezza per velocità: journaling solo dei metadati (veloce, comune) rispetto a metadati e dati.
Il kernel mette in cache i dati dei file in RAM nella page cache, così le riletture colpiscono la memoria e le scritture sono bufferizzate e scaricate (flush) più tardi (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)
L'I/O bufferizzato è veloce, ma i dati "scritti" non sono durevoli finché non c'è fsync; i database usano spesso direct I/O più il proprio buffer pool per controllare con precisione caching e durabilità.
Gli interni del filesystem spiegano comportamenti quotidiani: perché gli hard link funzionano, perché cancellare un file che un processo tiene ancora aperto non libera spazio finché non lo chiude, perché fsync è essenziale per la durabilità (e un classico bug di perdita dati quando viene omesso), e perché la seconda lettura di un file è istantanea (page cache). Gli ingegneri senior ragionano su questi aspetti quando scelgono buffered vs direct I/O per un database, dimensionano la RAM per la cache, o fanno il debug di un problema di coerenza dopo un crash.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona