Πώς λειτουργούν τα συστήματα αρχείων: inodes, journaling, και το page cache;

Question

IT Interview Practice · Accepted Answer

Ένα **σύστημα αρχείων (filesystem)** μετατρέπει έναν επίπεδο πίνακα από blocks δίσκου σε μια ιεραρχία αρχείων και φακέλων, διαχειριζόμενο τα metadata και τον ελεύθερο χώρο ώστε αυτό να είναι αξιόπιστο και γρήγορο.

## Inodes: ένα αρχείο είναι metadata + δείκτες blocks

Στα συστήματα αρχείων UNIX, κάθε αρχείο είναι ένα **inode** (index node) — μια δομή που κρατά τα **metadata** του αρχείου (μέγεθος, ιδιοκτήτη, δικαιώματα, χρονοσφραγίδες, αριθμό συνδέσμων) και **δείκτες προς τα blocks δεδομένων** του. Προσέξτε τι *δεν* αποθηκεύει ένα inode: το **όνομα του αρχείου**. Τα ονόματα ζουν σε **φακέλους (directories)**, που είναι απλώς αρχεία που αντιστοιχίζουν όνομα → αριθμό inode:

```text
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)──▶ ...
                                 └──────────────┘
```

Γι' αυτό ένα **hard link** είναι απλώς μια δεύτερη εγγραφή φακέλου που δείχνει στο ίδιο inode (link count 2), και γιατί το `rm` είναι στην πραγματικότητα `unlink` — αφαιρεί ένα όνομα και απελευθερώνει το inode μόνο όταν ο αριθμός συνδέσμων φτάσει στο μηδέν.

## Journaling: επιβίωση από τα crashes

Μια μοναδική λογική λειτουργία (π.χ. ένα append) αγγίζει πολλά blocks — το inode, το bitmap ελεύθερου χώρου, τα δεδομένα. Ένα crash στη μέση αφήνει το σύστημα αρχείων ασυνεπές. Ένα **journal** πρώτα γράφει τις προβλεπόμενες αλλαγές σε ένα log, και μετά τις εφαρμόζει· μετά από crash το FS ξαναπαίζει (replay) (ή απορρίπτει) το journal αντί για μια αργή πλήρη σάρωση (`fsck`). Οι λειτουργίες ανταλλάσσουν ασφάλεια με ταχύτητα: journal **μόνο των metadata** (γρήγορο, συνηθισμένο) έναντι metadata **και δεδομένων**.

## Page cache & διαδρομές I/O

Ο kernel κάνει cache τα δεδομένα των αρχείων στη RAM στο **page cache**, οπότε οι επαναναγνώσεις χτυπούν τη μνήμη και οι εγγραφές γίνονται **buffered** και flushed αργότερα (write-back):

```text
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 είναι γρήγορο, αλλά τα "γραμμένα" δεδομένα δεν είναι ανθεκτικά (durable) μέχρι το `fsync`· οι βάσεις δεδομένων συχνά χρησιμοποιούν **direct I/O** συν το δικό τους buffer pool για να ελέγχουν με ακρίβεια το caching και την ανθεκτικότητα.

## Γιατί έχει σημασία

Τα εσωτερικά του συστήματος αρχείων εξηγούν την καθημερινή συμπεριφορά: γιατί λειτουργούν τα hard links, γιατί η διαγραφή ενός αρχείου που μια διεργασία κρατά ακόμη ανοιχτό δεν απελευθερώνει χώρο μέχρι να κλείσει, γιατί το `fsync` είναι απαραίτητο για την ανθεκτικότητα (και ένα κλασικό bug απώλειας δεδομένων όταν παραλείπεται), και γιατί η δεύτερη ανάγνωση ενός αρχείου είναι ακαριαία (page cache). Οι senior μηχανικοί συλλογίζονται αυτά όταν επιλέγουν buffered vs direct I/O για μια βάση δεδομένων, όταν διαστασιολογούν τη RAM για cache, ή όταν κάνουν debug ένα ζήτημα crash-consistency.

Inodes: ένα αρχείο είναι metadata + δείκτες blocks

Journaling: επιβίωση από τα crashes

Page cache & διαδρομές I/O

Γιατί έχει σημασία

Σχετικές ερωτήσεις