Unix_FS

1. Il file system UNIX V7 (slide 81-83) — il capostipite

Questo è il filesystem storico (1979, PDP-11) che ha posto le basi concettuali per tutti i filesystem UNIX-like moderni, incluso ext4.

Caratteristiche chiave:

• Deriva da MULTICS, ed è il primo a rendere popolare lo schema albero gerarchico + link (che crea un grafo aciclico diretto, non un albero puro, perché un file può avere più genitori tramite hard link).
• Nome file: max 14 caratteri (limite durissimo per gli standard di oggi — niente / né NUL).
• Voce di directory: solo 16 byte totali → 2 byte per il numero di i-node + 14 byte per il nome. È una struttura fissa, semplicissima, niente di dinamico.
• Limite di 64K file per filesystem: deriva matematicamente dal fatto che il numero di i-node nella voce di directory è su 2 byte = 2^16 = 65536 valori possibili.
• L’i-node è la “verità” sul file: la directory dice solo “questo nome → questo numero di inode”; tutto il resto (permessi, dimensione, timestamp, owner, blocchi dati) vive nell’i-node, indicizzato in una tabella.

Algoritmo di ricerca (es. /usr/ast/mbox): #review

1. Si parte dall’i-node della root (sempre noto, fisso, es. i-node 1 in molti FS).
2. Si legge il contenuto della directory root come se fosse un file → si cerca la voce “usr” → si ottiene il suo numero di i-node.
3. Si legge l’i-node di “usr” → si trovano i blocchi dati di quella directory → si legge il suo contenuto → si cerca “ast” → si ottiene il suo i-node.
4. Si ripete per “mbox”.

Questo è esattamente il meccanismo di path resolution che usa anche Linux oggi (con l’aggiunta della dentry cache per velocizzarlo, come visto nelle slide su ext2).

Percorsi relativi: stesso identico algoritmo, ma si parte dall’i-node della cwd (current working directory) del processo invece che dalla root. . punta all’i-node della directory stessa, .. punta all’i-node del genitore — sono voci reali memorizzate fisicamente nella directory.

💡 Nota da esperto: questo design (semplice, rigido, a dimensione fissa) aveva gravi limiti di performance e frammentazione su disco — è esattamente il problema che la Berkeley FFS (Fast File System) risolse introducendo i cylinder group (antenato concettuale dei “gruppi di blocchi” di ext2 che hai visto a slide 42).

---

2. L’evoluzione della famiglia ext (slide 84-86)

Ext (1992)

Il primissimo filesystem nativo per il kernel Linux, scritto da Rémy Card. Risolveva il limite di 2GB del filesystem MINIX (che Linux usava all’inizio per necessità). È stato anche il primo a sfruttare il VFS del kernel Linux (quello che hai visto a slide 71-73).

Ext2 (1993)

Nasce per risolvere due problemi gravi di ext:

• Immutabilità degli i-node: in ext, una volta creato un i-node, certi suoi attributi non potevano essere modificati senza ricreare il file. Ext2 rende la gestione degli i-node flessibile.
• Frammentazione: introduce bitmap (stile MINIX) e la strategia di “vicinanza” file-directory che hai visto a slide 43 (allocare i file vicino alla directory genitore).

Ext2 batte un concorrente dell’epoca (Xiafs) principalmente per affidabilità a lungo termine. È quello descritto in dettaglio nelle slide 42-44 (superblocco, descrittore di gruppo, bitmap, preallocazione di 8 blocchi).

Il problema di ext2: nessun journaling → dopo un crash, serviva un fsck completo, che su disco grandi poteva richiedere ore.

Ext3

review

Stesso layout su disco di ext2, ma con l’aggiunta del journaling (lo stesso meccanismo generale spiegato a slide 67-68). Vantaggio enorme: è retrocompatibile — puoi montare un ext3 come ext2 (ignorando il journal) e viceversa puoi convertire ext2→ext3 senza riformattare.

Ext4 (2006-2008)

Nato come fork di ext3 (non semplice estensione, per non destabilizzare ext3 in produzione). Le novità principali:

• Extent: la rivoluzione più importante. Invece di elencare ogni singolo blocco di un file (come faceva l’i-node “classico” a slide 18-19, con indirizzi diretti + indiretti), un extent dice semplicemente:

  “a partire dal blocco X, i successivi N blocchi sono contigui e appartengono a questo file”

  Questo riduce drasticamente i metadati necessari per file grandi e contigui — un file di 1GB scritto in modo sequenziale può aver bisogno di un solo extent invece di migliaia di puntatori a blocco.

• JBD/JBD2 (Journaling Block Device): il motore di journaling, configurabile in 3 modalità:

  • journal: journaling completo (dati + metadati) — massima sicurezza, minor performance.
  • ordered (default): solo metadati nel journal, ma i dati vengono scritti prima dei metadati corrispondenti.
  • writeback: solo metadati nel journal, nessuna garanzia sull’ordine dei dati — più veloce, meno sicuro.

• Limiti enormi: file fino a 16 TB, filesystem fino a 1 EB (exabyte).

• Allocazione ritardata (delayed allocation) e allocazione multiblocco: il kernel aspetta il più possibile prima di decidere dove scrivere su disco, per poter allocare blocchi contigui più grandi (meno frammentazione, vedi anche slide 55 sulla preallocazione).

---

3. Btrfs — uno sguardo al futuro (slide 87-88)

Btrfs (“better F S” o “B-tree FS”) è concettualmente un’altra famiglia rispetto a ext: non è un’evoluzione incrementale, è un design nuovo basato su Copy-on-Write (COW).

Cos’è il COW e perché cambia tutto: Quando modifichi un blocco, Btrfs non lo sovrascrive mai in place. Scrive la nuova versione altrove e poi aggiorna i puntatori (in modo atomico). Questo ha due conseguenze enormi:

1. Niente “stato a metà” dopo un crash: i dati vecchi restano intatti finché il nuovo blocco non è scritto e confermato → coerenza quasi automatica, senza bisogno di journaling classico per i dati.
2. Gli snapshot diventano quasi gratis: uno snapshot è solo un nuovo puntatore alla stessa struttura ad albero esistente — non serve copiare nulla finché qualcosa non viene effettivamente modificato (da qui anche la deduplicazione “gratuita” quando duplichi un file).

Caratteristiche salienti:

• Supporto a file/filesystem enormi (16 EiB).
• RAID software integrato (0, 1, 1+0 stabili; 5/6 storicamente sperimentali e con bug noti — attenzione se vedi proporlo in produzione, è un punto debole reale di Btrfs).
• Checksum su dati e metadati: rileva corruzioni silenziose (bit rot) che ext4 non rileva.
• Compressione trasparente (zlib/lzo/zstd) e deduplicazione.
• Deframmentazione e resize online (filesystem montato e in uso).
• Allocazione dinamica degli i-node (ext ha un numero di i-node fissato alla creazione del FS — se lo riempi di milioni di file piccoli puoi “finire gli inode” anche con spazio disco libero; Btrfs non ha questo problema).

Confronto pratico ext4 vs Btrfs:

Aspetto	Ext4	Btrfs
Maturità	Altissima, “boring tech” che funziona da 15+ anni	Più recente, storicamente meno testato su carichi pesanti
Performance pure	Generalmente più rapido e predicibile	Overhead del COW su alcuni workload (es. database, VM)
Funzionalità	Solido ma “essenziale”	Snapshot, subvolumi, checksum, RAID nativo
Uso tipico	Server di produzione, root FS generico	Synology/QNAP NAS, openSUSE/Fedora desktop, backup con snapshot

---

4. Struttura delle cartelle in Linux — FHS (slide 89-91)

review

Questa è la Filesystem Hierarchy Standard (FHS), lo standard de facto che quasi tutte le distro seguono per organizzare /.

Punti da sottolineare oltre a quanto già scritto in slide:

• /etc = “etcetera” storicamente, oggi reinterpretato come “Editable Text Configuration” — contiene solo configurazione, mai binari o dati applicativi.
• /usr in origine era per i dati condivisibili tra più macchine in rete (da cui “user” ma anche “Unix System Resources” come retroacronimo) — oggi contiene la maggior parte del sistema installato (/usr/bin, /usr/lib, /usr/share).
• /var = dati che variano nel tempo durante l’esecuzione (log, cache, mail queue, database) — a differenza di /usr che è perlopiù statico dopo l’installazione.
• /dev = “everything is a file” filosofia UNIX: anche un disco fisico (/dev/sda) o una partizione (/dev/sda1) sono file speciali (device file), non semplici directory.
• /mnt vs /media: /media è per mount automatici di dispositivi removibili gestiti dal desktop environment (una chiavetta USB che inserisci e appare da sola); /mnt è per mount manuali e temporanei fatti dall’amministratore con il comando mount.

💡 Nota da esperto — trend attuale (usrmerge): nelle distro moderne (Debian/Ubuntu recenti, Fedora, Arch), /bin, /sbin e /lib sono spesso link simbolici a /usr/bin, /usr/sbin, /usr/lib. Questo (chiamato “usrmerge”) semplifica situazioni in cui /usr deve poter essere montato separatamente all’avvio in modo coerente con la root.

Vale anche la pena menzionare due filesystem virtuali che non sono nello schema ma sono fondamentali e che incontrerai sempre: /proc (procfs — espone lo stato del kernel e dei processi come file virtuali, non risiede su disco) e /sys (sysfs — espone i device del kernel, usato anche dai driver).

---

5. Comandi pratici: vedere e montare partizioni (slide 92-93)

Qui la teoria del VFS (slide 71-73: superblocco, v-node, registrazione del FS) diventa operativa.

Vedere cosa c’è (slide 92)

lsblk

Mostra l’albero dei block device in formato leggibile: disco → partizioni, con SIZE, TYPE (disk/part), e MOUNTPOINTS (dove sono montati, se lo sono). È il comando che uso quasi sempre per primo.

sudo fdisk -l

Più verboso: mostra anche la tabella delle partizioni (MBR o GPT — collegamento diretto alle slide 6-8!), tipo di partizione, dimensione esatta in settori.

mount -l
# oppure, più moderno e leggibile:
findmnt

Elenca i filesystem attualmente montati, con le opzioni di mount attive (es. rw, noatime, errors=remount-ro).

Montare (slide 93)

Il concetto chiave (che collega questa slide al VFS visto prima): una partizione formattata con un filesystem esiste sul disco, ma non è accessibile dall’albero / finché non viene “agganciata” (mount) a un punto specifico — esattamente il momento in cui il VFS crea il superblock in memoria e lo registra (slide 73).

sudo mkdir -p /mnt/mydisk          # 1. la directory di destinazione deve esistere
sudo mount -t ext4 /dev/sdb1 /mnt/mydisk   # 2. monto specificando il tipo
sudo mount -o ro /dev/sdb1 /mnt/mydisk     # variante: sola lettura

Per smontare sempre prima di staccare fisicamente un disco, per evitare perdita di dati (ricorda la buffer cache di slide 49-54: i dati modificati potrebbero non essere ancora scritti su disco!):

sudo umount /mnt/mydisk

🎯 Il pezzo che manca nelle slide: /etc/fstab

Le slide si fermano al mount manuale, ma nella pratica reale il mount manuale è temporaneo (sparisce al riavvio). Per montare automaticamente una partizione a ogni boot, si usa il file /etc/fstab, con righe come:

UUID=1234-5678  /mnt/mydisk  ext4  defaults  0  2

Per trovare l’UUID di una partizione (più robusto di /dev/sdb1, che può cambiare nome se aggiungi/rimuovi dischi):

sudo blkid

Questo chiude il cerchio tra teoria (FS, VFS, mount point) e amministrazione di sistema reale.

---

Hardware