I filesystem

Cosa sono i filesystem?

Un filesystem comprende i metodi e le strutture di dati usate da un sistema operativo per tenere traccia dei file su un hard disk o su una sua partizione, cioè il modo in cui i file sono organizzati sui dischi. La parola viene anche usata per riferirsi ad una partizione o a un disco usato per immagazzinare i file, o al tipo del filesystem stesso, quindi si può dire ``ho due filesystem'' per indicare che si hanno due partizioni in cui immagazzinare file, o che si sta usando ``il filesystem extended'' per indicarne il tipo.

La differenza tra un disco o una partizione ed il filesystem che esso contiene è molto importante. Alcuni programmi (compreso, abbastanza ragionevolmente, quelli che creano i filesystem) operano direttamente sui settori del disco o della partizione; se c'è un filesystem esistente, questo verrà distrutto o seriamente danneggiato. La maggior parte dei programmi operano su un filesystem e quindi non funzioneranno su una partizione che non ne contiene uno (o che ne contiene uno del tipo sbagliato).

Prima che si possa usare un disco o una partizione come filesystem, questo deve essere inizializzato e bisogna scriverci le strutture di dati per l'archiviazione: questo processo si chiama creazione di un filesystem.

La maggior parte dei tipi di filesystem UNIX hanno una struttura generale simile, anche se i dettagli esatti cambiano abbastanza. I concetti centrali sono quelli di superblocco, inode, blocco dati, blocco directory e blocco indirezione. Il superblocco contiene delle informazioni sul filesystem intero, come la sua dimensione (l'informazione esatta qui dipende dal filesystem). Un inode contiene tutte le informazioni su un file eccetto il suo nome, che viene immagazzinato nella directory insieme con il numero dell'inode. Una voce di directory consiste del nome di un file e del numero dell'inode che lo rappresenta. L'inode contiene il numero di diversi blocchi dati, che vengono usati per immagazzinare i dati del file. Nell'inode c'è posto solo per alcuni numeri di blocchi dati, ma se ne servono più viene allocato dinamicamente più spazio per i puntatori ai blocchi dati. Questi blocchi allocati dinamicamente sono blocchi indiretti; il nome indica che per trovare i blocchi dati bisogna trovare prima il numero all'interno del blocco indiretto.

I filesystem UNIX di solito permettono di creare un buco in un file (si fa con lseek; controllate la pagina man), cioè il filesystem fa solo finta che in un posto particolare nel file ci sono solo byte zero, ma per quel posto nel file non viene riservato nessun settore di disco reale (cioè il file userà un po' meno spazio disco). Accade spesso solo per i file binari piccoli, le librerie condivise di Linux, alcuni database ed alcuni altri casi speciali (i buchi sono implementati immagazzinando un valore speciale come indirizzo del blocco dati nel blocco indiretto o nell'inode. Questo indirizzo speciale significa che non viene allocato nessun blocco dati per quella parte del file e quindi che questo ha un buco).

I buchi sono moderatamente utili. Sul sistema dell'autore una semplice misura ha mostrato un potenziale per circa 4 MB di risparmio usando buchi, su un totale di 200 MB di spazio disco usato. Quel sistema, però, contiene pochi programmi e nessun file di database.

Filesystem a go-go

Linux supporta diversi tipi di filesystem. Al momento in cui sto scrivendo, i più importanti sono:

Oltre a questi vengono supportati molti filesystem di altri sistemi operativi, per rendere più semplice lo scambio di file; questi filesystem funzionano come quelli nativi, tranne per la mancanza di alcune caratteristiche normali di quelli UNIX, oppure hanno delle limitazioni curiose o altre stranezze.

La scelta del filesystem da usare dipende dalla situazione: se ci sono ragioni di compatibilità o altri motivi che rendono indispensabile l'uso di uno dei filesystem non nativi, deve essere usato quello, se si può scegliere liberamente allora probabilmente la scelta più saggia è l'ext2, dato che ha tutte le caratteristiche e la sua performance è la migliore.

Esiste anche il filesystem proc, di solito accessibile nella directory /proc, che in realtà non è per niente un filesystem anche se gli assomiglia. Il filesystem proc permette di avere facile accesso ad alcune strutture di dati del kernel, come la lista dei processi (da cui il nome); fa apparire queste strutture di dati come un filesystem, che può essere manipolato con i normali strumenti per i file. Ad esempio, per avere un elenco di tutti i processi si può usare il comando

$ ls -l /proc
total 0
dr-xr-xr-x   4 root     root            0 Jan 31 20:37 1
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 63
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 94
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 95
dr-xr-xr-x   4 root     users           0 Jan 31 20:37 98
dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 99
-r--r--r--   1 root     root            0 Jan 31 20:37 devices
-r--r--r--   1 root     root            0 Jan 31 20:37 dma
-r--r--r--   1 root     root            0 Jan 31 20:37 filesystems
-r--r--r--   1 root     root            0 Jan 31 20:37 interrupts
-r--------   1 root     root      8654848 Jan 31 20:37 kcore
-r--r--r--   1 root     root            0 Jan 31 11:50 kmsg
-r--r--r--   1 root     root            0 Jan 31 20:37 ksyms
-r--r--r--   1 root     root            0 Jan 31 11:51 loadavg
-r--r--r--   1 root     root            0 Jan 31 20:37 meminfo
-r--r--r--   1 root     root            0 Jan 31 20:37 modules
dr-xr-xr-x   2 root     root            0 Jan 31 20:37 net
dr-xr-xr-x   4 root     root            0 Jan 31 20:37 self
-r--r--r--   1 root     root            0 Jan 31 20:37 stat
-r--r--r--   1 root     root            0 Jan 31 20:37 uptime
-r--r--r--   1 root     root            0 Jan 31 20:37 version
$

Notate che anche se si chiama filesystem, nessuna parte di proc tocca nessun disco: esiste solo nell'immaginazione del kernel. Quando si cerca di guardare una qualsiasi parte del filesystem proc, il kernel fa sembrare che esista da qualche parte, ma non è così; quindi, anche se c'è un file /proc/kcore di qualche mega, non occupa spazio disco.

Quale filesystem bisogna usare?

Di solito non ci sono molte ragioni per usare diversi filesystem. Al momento, l'ext2fs è il più comune e probabilmente è la scelta più saggia. A seconda delle necessità globali di strutture di archiviazione, velocità, affidabilità (apparente), compatibilità e svariate altre ragioni può essere consigliabile usare un altro filesystem. La scelta va fatta caso per caso.

Come creare un filesystem

I filesystem vengono creati, cioè inizializzati, con il comando mkfs. In realtà esiste un programma separato per ciascun tipo di filesystem e mkfs è solo un'interfaccia che avvia quello adatto a seconda del tipo di filesystem desiderato. Il tipo viene selezionato con l'opzione -t tipofs.

I programmi richiamati da mkfs hanno interfacce su linea di comando leggermente diverse. Le opzioni più comuni ed importanti sono riassunte qui sotto; per altri dettagli consultare la pagina man.

Per creare un filesystem ext2 su un floppy si dovrebbero dare i seguenti comandi:

$ fdformat -n /dev/fd0H1440
Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.
Formatting ... done
$ badblocks /dev/fd0H1440 1440 $>$ bad-blocks
$ mkfs -t ext2 -l bad-blocks /dev/fd0H1440
mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10
360 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
Block size=1024 (log=0)
Fragment size=1024 (log=0)
1 block group
8192 blocks per group, 8192 fragments per group
360 inodes per group

Writing inode tables: done
Writing superblocks and filesystem accounting information: done
$

Si poteva usare nello stesso modo l'opzione -c di mkfs invece di badblocks ed un file separato, come riportato nell'esempio qui sotto.

$ mkfs -t ext2 -c /dev/fd0H1440
mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10
360 inodes, 1440 blocks
72 blocks (5.00%) reserved for the super user
First data block=1
Block size=1024 (log=0)
Fragment size=1024 (log=0)
1 block group
8192 blocks per group, 8192 fragments per group
360 inodes per group

Checking for bad blocks (read-only test): done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
$

Il processo per preparare i filesystem sugli hard disk o sulle partizioni è lo stesso che per i floppy, tranne che non è necessario formattarli.

Montare e smontare un filesystem

Prima che si possa usare un filesystem, bisogna montarlo. In quel momento il sistema operativo compie varie operazioni di archiviazione in modo da essere sicuri che tutto funzioni. Dato che tutti i file in UNIX si trovano in un singolo albero di directory, l'operazione di mount farà sembrare che il nuovo filesystem sia contenuto in una sottodirectory esistente di qualche filesystem già montato.

Ad esempio, la Figura 4-3 mostra tre filesystem separati, ciascuno con la propria directory principale; quando gli ultimi due vengono montati sotto /home e /usr sul primo filesystem, abbiamo un singolo albero di directory, come in Figura 4-4.

I comandi per montare questi due filesystem sono riportati nel seguente esempio:

$ mount /dev/hda2 /home
$ mount /dev/hda3 /usr
$

Linux supporta molti tipi di filesystem; mount cerca di indovinare il tipo di quello che si sta montando. Si può anche usare l'opzione -t tipofs per specificare direttamente il tipo: talvolta è necessaria, dato che l'euristica usata da mount non sempre funziona. Ad esempio per montare un floppy MS-DOS si usa il seguente comando:

$ mount -t msdos /dev/fd0 /floppy
$

La directory su cui si monta il filesystem può anche non essere vuota, ma deve esistere. Qualsiasi file vi si trovi non potrà essere richiamato per nome mentre il filesystem è montato (qualsiasi file già aperto sarà ancora accessibile; i file a cui puntano hard link da altre directory possono essere accessibili usando quei nomi). Questo procedimento permette di non perdere nessun dato e può anche essere utile: ad esempio, alcuni vogliono avere /tmp e /var/tmp sinonimi, e rendere /tmp un link simbolico a /var/tmp. Quando si avvia il filesystem, prima che venga montato /var, viene usata una directory /var/tmp che risiede sul filesystem radice. Quando viene montato /var, la directory /var/tmp sul filesystem radice diventa inaccessibile. Se non esistesse /var/tmp, sarebbe impossibile usare i file temporanei prima di montare /var.

Se non volete scrivere niente su un filesystem, usate l'opzione -r per montarlo a sola lettura; in questo modo il kernel interromperà qualsiasi tentativo di scrivervi ed eviterà di aggiornare i tempi di accesso ai file negli inode. È indispensabile usare i mount a sola lettura per i mezzi non scrivibili, come i CD-ROM.

Il lettore attento avrà già notato un piccolo problema logistico: come viene montato il primo filesystem (chiamato filesystem radice, perché contiene la directory principale), dato che ovviamente non può essere montato su un altro filesystem? Beh, la risposta è che si usa la magia[1]. Il filesystem radice viene montato magicamente al momento dell'avvio del sistema e resta sempre montato. Se all'avvio non è possibile farlo, il sistema non parte. Il nome del filesystem che viene montato magicamente come radice è compilato nel kernel, o impostato usando LILO o rdev.

Il filesystem radice viene di solito montato inizialmente a sola lettura, gli script di avvio poi attivano fsck per verificare che sia valido e se non ci sono problemi lo rimonteranno con i permessi di scrittura. fsck non deve essere usato su un filesystem montato, dato che qualsiasi modifica al filesystem mentre sta girando fsck farà dei danni. Dato che il filesystem radice è montato a sola lettura mentre viene controllato, fsck può correggere qualsiasi problema senza preoccupazioni, dato che l'operazione di remount ripulirà tutti i metadati che il filesystem tiene in memoria.

Su molti sistemi ci sono altri filesystem che devono essere montati automaticamente al momento dell'avvio: questi vengono specificati nel file /etc/fstab; consultate la pagina man di fstab per avere dettagli sul suo formato. I dettagli di quando esattamente vengono montati i vari filesystem dipendono da molti fattori, e possono essere configurati, se serve, dall'amministratore; vedere il Capitolo 6.

Quando non serve più che un filesystem sia montato, può essere smontato usando umount[2]. umount accetta un argomento: il file di device o il punto di mount. Ad esempio, per smontare le directory dell'esempio precedente, si possono usare i comandi

$ umount /dev/hda2
$ umount /usr
$

Consultare la pagina man per avere altre istruzioni su come usare il comando. È indispensabile smontare sempre i floppy montati: non li tirate direttamente fuori dal lettore! A causa delle operazioni di cache su disco, i dati non vengono necessariamente scritti sul floppy finché non lo smontate, quindi rimuovendo il floppy dal lettore troppo presto se ne possono corrompere i contenuti. Se leggete dal floppy soltanto non è molto probabile, ma se ci scrivete, anche accidentalmente, i risultati possono essere catastrofici.

Montare e smontare un filesystem richiede privilegi di superutente, cioè lo può fare solo root; la ragione è che se chiunque potesse montare un dischetto su una qualsiasi directory, sarebbe piuttosto facile creare un floppy diciamo con un cavallo di Troia camuffato da /bin/sh, o da un qualsiasi programma usato spesso. Comunque, spesso è necessario permettere agli utenti di usare i floppy, ed ecco alcuni modi per poterlo fare:

• Dare agli utenti la password di root. Ovviamente è un buco di sicurezza, ma è la soluzione più facile, ed è adatto a quei sistemi dove non c'è comunque bisogno di sicurezza, come molti sistemi personali, non in rete.

• Usare un programma come sudo per permettere agli utenti di usare mount. Anche questo crea problemi di sicurezza, ma non dà direttamente privilegi di superutente a chiunque[3].

• Fare usare agli utenti mtools, un pacchetto per manipolare i filesystem MS-DOS senza montarli. Funziona bene se l'unica cosa che serve sono dischetti MS-DOS, altrimenti è piuttosto complicato.

• Elencare i dispositivi floppy e i loro punti di mount permessi, insieme con le opzioni adatte, in /etc/fstab.

/dev/fd0            /floppy      msdos   user,noauto      0     0

L'opzione noauto evita che il filesystem venga montato automaticamente all'avvio del sistema (cioè non lo fa montare da mount -a). L'opzione user permette a qualsiasi utente di montare il filesystem e per sicurezza disabilita l'esecuzione di programmi (normali o setuid) e l'interpretazione di file di device dal filesystem montato. Fatto questo, qualsiasi utente può montare un floppy con un filesystem msdos usando il seguente comando:

$ mount /floppy
$

Se volete dare accesso a diversi tipi di floppy, dovete dare diversi punti di mount. Le impostazioni possono essere diverse per ogni punto di mount, ad esempio, per dare accesso sia a floppy MS-DOS che ext2, si possono inserire in /etc/fstab:

/dev/fd0    /dosfloppy    msdos   user,noauto  0  0
/dev/fd0    /ext2floppy   ext2    user,noauto  0  0

Il controllo dell'integrità di un filesystem con fsck

I filesystem sono creature complesse e come tali tendono ad essere in qualche modo propense ad avere errori. Si possono controllare la correttezza e la validità di un filesystem usando il comando fsck, che può essere usato per riparare i piccoli errori che trova e per avvisare l'utente se ci sono problemi irreparabili. Fortunatamente al codice per implementare i filesystem viene fatto un debug piuttosto efficace, quindi in genere non ci sono problemi e se ci sono sono causati da mancanza di corrente, guasti hardware o errori dell'operatore, ad esempio non fare correttamente lo shutdown del sistema.

La maggior parte dei filesystem fanno fsck automaticamente all'avvio del sistema, in modo che gli errori vengono individuati (e, speriamo, corretti) prima che il filesystem venga usato. Usare un filesystem corrotto tende a peggiorare le cose: se le strutture di dati non sono integre, usare il filesystem probabilmente le danneggerà ancora di più e verranno persi sempre più dati. Comunque, fsck può metterci un po' di tempo per controllare un filesystem grande e, dato che non ci sono quasi mai errori se il sistema viene spento in modo corretto, si possono usare un paio di trucchi per evitare di fare il controllo in casi del genere: il primo è che se esiste il file /etc/fastboot non vengono fatti controlli. Il secondo è che il filesystem ext2 ha un codice speciale nel superblocco che dice se il filesystem è stato smontato in maniera corretta l'ultima volta; in questo modo e2fsck (la versione di fsck per filesystem ext2) può evitare di controllare i filesystem se il codice indica che è stato smontato correttamente (l'assunzione è che se il filesystem è stato smontato bene non ci sono problemi). La validità del trucco del file /etc/fastboot dipende dallo script di avvio, ma il trucco dell'ext2 funziona tutte le volte che si usa e2fsck---per evitarlo deve essere esplicitamente indicata un'opzione (consultate la pagina man di e2fsck per i dettagli).

Il controllo automatico funziona solo per i filesystem che vengono montati automaticamente all'avvio; usate fsck a mano per gli altri, come ad esempio per i floppy.

Se fsck trova dei problemi irrecuperabili dovete avere una conoscenza profonda di come funzionano i filesystem in generale e del tipo del filesystem corrotto in particolare, oppure dovete avere dei buoni backup. La seconda possibilità è più facile (anche se spesso più noiosa), per la prima ci si può appoggiare ad un amico, o ai newsgroup e alle mailing list su Linux, o ad una qualche altra forma di aiuto, se non avete voi stessi le nozioni necessarie. Mi piacerebbe dirvi di più sull'argomento, ma mi trattiene la mia mancanza di esperienza e di conoscenza in questo campo. Vi dovrebbe essere utile il programma debugfs di Theodore T'so.

fsck deve essere usato solo sui filesystem non montati, mai su quelli montati (con l'eccezione della radice a sola lettura durante l'avvio), perché accede al disco a basso livello e quindi può modificare il filesystem senza che il sistema operativo se ne accorga. È veramente un problema, se si fa confondere il sistema operativo.

Il controllo degli errori sul disco con badblocks

Può essere una buona idea controllare periodicamente se ci sono blocchi danneggiati, con il comando badblocks, che dà in output un elenco dei numeri dei blocchi danneggiati che trova. Si può usare questa lista per farla registrare nelle strutture dati del filesystem a fsck in modo che il sistema operativo non provi ad usare i blocchi danneggiati per scriverci dei dati. Nell'esempio viene spiegato come fare:

$ badblocks /dev/fd0H1440 1440 > bad-blocks
$ fsck -t ext2 -l bad-blocks /dev/fd0H1440
Parallelizing fsck version 0.5a (5-Apr-94)
e2fsck 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Check reference counts.
Pass 5: Checking group summary information.

/dev/fd0H1440: ***** FILE SYSTEM WAS MODIFIED *****
/dev/fd0H1440: 11/360 files, 63/1440 blocks
$

Combattere la frammentazione

Quando si scrive un file sul disco, non lo si può sempre fare su blocchi consecutivi; un file per cui non è stato possibile farlo si definisce frammentato. Ci vuole più tempo per leggere un file frammentato, dato che la testina di lettura e scrittura del disco si deve spostare di più, quindi è preferibile evitare la frammentazione, anche se questa è un problema meno grave nei sistemi con una buona cache di buffer con il read-ahead.

Il filesystem ext2 tenta di mantenere la frammentazione al minimo, tenendo tutti i blocchi di un file vicini, anche se non possono essere immagazzinati in settori consecutivi. L'ext2 in effetti alloca sempre il blocco libero che si trova più vicino agli altri blocchi di un file. Per l'ext2, quindi, è molto raro doversi preoccupare della frammentazione, ma esiste un programma di deframmentazione anche per i filesystem ext2: consultate [DEFRAG].

Ci sono molti programmi di deframmentazione per MS-DOS che spostano i blocchi nel filesystem per rimuovere la deframmentazione. Per altri tipi di filesystem si deve fare un backup completo, ricreare il filesystem e recuperare i dati dai backup. Fare il backup prima di deframmentare un filesystem è una buona idea in ogni caso, dato che molte cose possono andare storte nel processo.

Altri strumenti per tutti i filesystem

Anche altri strumenti sono utili per gestire i filesystem: df mostra lo spazio disco libero su uno o più filesystem, du quello occupato da una directory e da tutti i suoi file. Si possono usare entrambi questi comandi per ricercare chi spreca spazio disco.

sync forza la scrittura sul disco di tutti i blocchi non scritti nella cache di buffer (vedi la la sezione La cache di buffer nel Capitolo 5). Normalmente non c'è bisogno di farlo a mano: lo fa automaticamente il processo daemon update. Può essere utile in caso di catastrofe, ad esempio se update o il suo aiutante bdflush muoiono, o se dovete interrompere la corrente ora e non potete aspettare che venga avviato update.

Altri strumenti per il filesystem ext2

In aggiunta al comando per creare i filesystem (mke2fs) e quello per controllarli (e2fsck), accessibili direttamente o attraverso le interfacce indipendenti dal tipo di filesystem, il filesystem ext2 ha altri strumenti utili.

tune2fs migliora i parametri del filesystem. Alcuni di quelli più interessanti sono:

• Il numero massimo di mount. e2fsck forza un controllo ogni volta che un filesystem viene montato troppe volte, anche se ha il codice di filesystem integro. Per un sistema che viene usato per sviluppare o testare il sistema, può essere una buona idea ridurre questo limite.

• Il tempo massimo tra i controlli. e2fsck può anche forzare un controllo dopo un tempo massimo, anche se c'è il codice di filesystem pulito e il filesystem non è stato montato molto spesso. Questo parametro può essere anche disabilitato.

• Il numero di blocchi riservato per root. L'ext2 riserva alcuni blocchi per root in modo che se il filesystem si riempie sia ancora possibile fare dell'amministrazione di sistema senza dover cancellare niente. La percentuale riservata è per default del 5%, che sulla maggior parte dei dischi non è tanto da essere uno spreco. Comunque, per i floppy non c'è motivo per riservare niente.

dumpe2fs dà delle informazioni su un filesystem ext2, prese per la maggior parte dal suo superblocco. In Figura 4-5 viene mostrato un esempio di output. Alcune delle informazioni dell'output sono tecniche e richiedono una comprensione di come funziona il filesystem (vedere [EXT2FS-SLIDES]), ma la peggior parte è facilmente comprensibile.

debugfs è un debugger per i filesystem: permette accesso diretto alle strutture dati immagazzinate sul disco e quindi può essere usato per riparare gli errori che non possono essere corretti automaticamente con fsck. È stato anche usato per recuperare dei file cancellati; comunque, debugfs richiede di capire a fondo quello che si sta facendo: se non riuscite a capire qualcosa potreste distruggere tutti i dati.

Per fare il backup di un filesystem ext2 si possono usare dump e restore: si tratta di versioni specifiche per questo tipo di filesystem degli strumenti tradizionali di backup di UNIX. Vedere il Capitolo 10 per altre informazioni sui backup.