11.10 Messa a Punto dei Dischi

11.10.1.1 vfs.vmiodirenable

La variabile sysctl vfs.vmiodirenable può essere impostata a 0 (inattivo) o 1 (attivo); di default è 1. Questa variabile controlla il modo in cui le directory vengono messe nella cache dal sistema. La maggior parte delle directory è piccola, ed usa solo un singolo frammento (tipicamente 1 K) nel file system e meno (tipicamente 512 byte) nella cache. Ad ogni modo, quando si lavora nella modalità predefinita il buffer manterrà soltanto un numero fissato di directory anche se hai una quantità enorme di memoria. Attivando questa sysctl si permette al buffer di usare la VM Page Cache per immagazzinare le directory, rendendo disponibile tutta la memoria disponibile per il caching delle directory. In ogni caso, la minima quantità di memoria usata per memorizzare una directory sarà la dimensione della pagina fisica (in genere 4 K) invece di 512 byte. Noi consigliamo di attivare questa opzione se si hanno in esecuzione dei servizi che manipolano un grosso numero file. Servizi di questo tipo sono le cache web, i grandi sistemi di posta, e quelli di news. Attivare questa opzione in generale non ridurrà le prestazioni nonostante la memoria sprecata, ma dovresti sperimentare tu stesso per verificare.

11.10.1.2 hw.ata.wc

FreeBSD 4.3 ha giocato un po' con l'idea di disattivare il caching IDE in scrittura. Questo ha ridotto la larghezza di banda in scrittura verso i dischi IDE ma è stato considerato necessario a causa di gravi problemi di consistenza dei dati introdotti dai venditori di dischi rigidi. Il problema è che il disco IDE rimane inattivo dopo che una scrittura è stata completata. Con il caching in scrittura attivo, i dischi IDE non scrivono soltanto i dati sui dischi in maniera disordinata, ma talvolta rimandano la scrittura indefinitamente sotto carichi di lavoro del disco pesanti. Un crash o un calo di tensione possono condurre a seri problemi di corruzione del file system. L'impostazione predefinita di FreeBSD fu cambiata in favore della sicurezza. Sfortunatamente, il risultato è stato una perdita di prestazioni talmente tremenda che abbiamo dovuto reinserire il caching in scrittura di default dopo quella release. Dovresti verificare il valore di default sul tuo sistema osservando la variabile sysctl hw.ata.wc. Se il caching IDE in scrittura è disattivato, potete attivarlo reimpostando la variabile del kernel a 1. Questo dovrebbe essere effettuato dal boot loader all'avvio. Tentare di effettuare questo cambiamento dopo che il kernel è stato avviato non avrà nessun effetto.

Per maggiori informazioni, guarda ata(4).

11.10.2.1 Maggiori dettagli sui Soft Updates

Ci sono due approcci tradizionalmente nella scrittura dei meta-dati del file system su disco. (Gli aggiornamenti dei meta-dati sono aggiornamenti ai dati che non sono contenuto, come gli inode o le directory.)

Storicamente, il comportamento predefinito era di scrivere gli aggiornamenti dei meta-dati in maniera sincrona. Se una directory veniva modificata, il sistema attendeva finché il cambiamento venisse effettivamente scritto su disco. I buffer con i dati dei file (i contenuti dei file) venivano passati attraverso la cache e salvati su disco in seguito, in maniera asincrona. Il vantaggio di questa implementazione è che avviene in maniera sicura. Se si verifica un problema durante un aggiornamento, i meta-dati sono sempre in uno stato consistente. Un file viene creato completamente o non viene creato affatto. Se i blocchi dati di un file non sono riusciti ad uscire dalla cache e arrivare al disco prima del crash, fsck(8) è in grado di capirlo e riparare il file system impostando a zero la lunghezza del file. Inoltre, l'implementazione è chiara e semplice. Lo svantaggio è che i cambiamenti dei meta-dati sono lenti. Un rm -r, ad esempio, tocca tutti i file in una directory consecutivamente, ma ogni cambiamento della directory (la cancellazione del file) verrà scritto su disco in maniera sincrona. Questo include gli aggiornamenti alla directory stessa, alla tabella degli inode, e magari anche ai blocchi indiretti allocati dal file. Simili considerazioni si applicano nell'elenco di grosse gerarchie (tar -x).

Il secondo caso è l'aggiornamento asincrono dei meta-dati. Questo è il comportamento predefinito per Linux/ext2fs e mount -o async per *BSD/ufs. Anche tutti gli aggiornamenti dei meta-dati vengono semplicemente fatti passare attraverso la cache, cioè vengono mescolati con gli aggiornamenti dei dati contenuti nel file. Il vantaggio di questa implementazione è che non c'è bisogno di attendere che ogni aggiornamento dei meta-dati venga scritto su disco, dunque tutte le operazioni che causano enormi quantità di aggiornamenti dei meta-dati lavorano molto più velocemente che nel caso sincrono. Inoltre, l'implementazione è ancora semplice e chiara, dunque c'è un basso rischio che si annidino dei bug nel codice. Lo svantaggio è che non c'è nessuna garanzia di uno stato consistente del file system. Se si verifica un problema durante un'operazione che ha aggiornato grandi quantità di meta-dati (ad esempio un abbassamento di tensione, o qualcuno che preme il tasto reset), il file system verrà lasciato in uno stato imprevedibile. Non c'è opportunità di esaminare lo stato del file system quando il sistema viene riavviato; i blocchi dati di un file potrebbero essere già stati scritti sul disco mentre gli aggiornamenti della tabella degli inode o la directory associata non lo sono. È praticamente impossibile implementare un fsck che sia in grado di ripulire il caos risultante (perché i dati necessari non sono disponibili sul disco). Se il file system è stato danneggiato più del riparabile, la sola scelta è di usare newfs(8) per ricrearlo e recuperarlo da un backup.

La soluzione comune di questo problema era implementare la registrazione delle regioni sporche, a cui spesso si fa riferimento come journaling, anche se questo termine non viene usato coerentemente e talvolta viene applicato ad altre forme di logging delle transazioni. Gli aggiornamenti dei meta-dati sono ancora scritti in maniera sincrona, ma solo in una piccola regione del disco. In seguito vengono spostati nella posizione appropriata. Poiché l'area di registrazione è una piccola regione contigua sul disco, non ci sono lunghe distanze da percorrere per le testine del disco, anche durante le operazioni pesanti, dunque queste operazioni sono più veloci degli aggiornamenti sincroni. Inoltre la complessità dell'implementazione è piuttosto limitata, dunque il rischio che si presentino dei bug è basso. Uno svantaggio è che tutti i meta-dati vengono scritti due volte (una volta nella regione di logging ed un altra nella posizione appropriata) e quindi per un lavoro normale si può avere un “peggioramento” delle prestazioni. D'altro canto, in caso di crash, tutti le operazioni sui meta-dati in sospeso possono essere velocemente annullate o recuperate dall'area di registrazione quando il sistema è di nuovo attivo, e come risultato si ha un avvio veloce del file system.

Kirk McKusick, lo sviluppatore del Berkeley FFS, ha risolto questo problema con i Soft Updates: tutti gli aggiornamenti dei meta-dati vengono tenuti in memoria e vengono scritti su disco in sequenza ordinata (“aggiornamenti ordinati dei meta-dati”). Ciò porta all'effetto che, in caso di operazioni pesanti sui meta-dati, gli ultimi aggiornamenti ad un elemento “recuperano” i precedenti se questi sono ancora in memoria e non sono già stati scritti su disco. Dunque tutte le operazioni, diciamo su una directory, vengono effettuate principalmente in memoria prima che l'aggiornamento sia scritto su disco (i blocchi dei dati vengono ordinati in relazione alla loro posizione, in modo che non vengano scritti su disco prima dei loro meta-dati). Se il sistema va in crash, ciò causa un implicito “riavvolgimento del log”: tutte le operazioni che non hanno ancora trovato posto sul disco appariranno come mai effettuate. Viene mantenuto uno stato consistente del file system che sarà quello di 30 o 60 secondi prima. L'algoritmo usato garantisce anche che tutte le risorse in uso siano marcate come tali nelle appropriate tabelle di bit: blocchi e inode. Dopo un crash, il solo errore di allocazione è che vengono marcate come “usate” anche risorse che sono effettivamente “libere”. fsck(8) riconosce questa situazione, e libera le risorse che non sono più in uso. Non c'è pericolo nell'ignorare lo stato di sporcizia del file system dopo un crash montandolo di forza con mount -f. Per poter liberare le risorse che potrebbero essere non usate, fsck(8) ha bisogno di essere avviato in seguito. Questa è l'idea di un fsck in background: all'avvio del sistema, viene registrata solo una immagine del file system. fsck può essere eseguito in seguito. Tutti i file system possono essere montati “sporchi”, quindi il processo di avvio del sistema procede in modalità multiutente. In seguito, fsck viene avviato su tutti i file system dove è necessario, per liberare le risorse che potrebbero essere inutilizzate. (I file system che non usano i Soft Updates hanno ancora bisogno del solito fsck, comunque.)

Il vantaggio è che le operazioni sui meta-dati sono veloci quasi come gli aggiornamenti asincroni (cioè più veloci che con il logging, che deve scrivere i meta-dati due volte). Gli svantaggi sono nella complessità del codice (che implica un maggiore rischio di trovare bug in un'area molto sensibile, essendo legata alla perdita dei dati degli utenti), ed un consumo di memoria maggiore. Inoltre ci sono alcune idiosincrasie alle quali ci si deve abituare. Dopo un crash, lo stato del file system appare in qualche modo “vecchio”. In situazioni dove l'approccio sincrono avrebbe causato la permanenza di alcuni file di lunghezza zero dopo un fsck, questi file non esistono affatto con un file system con Soft Updates, perché né i meta-dati né i contenuti dei file sono mai stati scritti su disco. Lo spazio su disco non viene rilasciato finché gli aggiornamenti non sono stati scritti su disco, il che può avvenire qualche tempo dopo che è stato eseguito rm. Questo potrebbe causare problemi durante l'installazione di grandi quantità di dati su un file system che non avesse abbastanza spazio per contenere tutti i file due volte.