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 sono piccole, e usano solo un singolo frammento
(tipicamente 1 K) nel file system e meno (tipicamente
512 byte) nella cache.
Con questa variabile impostata a 0, il buffer manterrà soltanto
un numero fissato di directory nella cache 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.
La variabile sysctl vfs.write_behind
ha il valore predefinito di 1
(attivo).
Essa dice al file system
di effettuare le scritture sul media quando vengono raccolti
cluster completi, il che accade tipicamente
quando si scrivono grossi file sequenziali. L'idea è di
evitare la saturazione del buffer cache con buffer
«sporchi» quando le prestazioni dell'I/O non ne
trarrebbero giovamento. Ad ogni modo, questo può causare uno
stallo dei processi, ed in alcune circostanze potreste desiderare di
disabilitarlo.
La variabile sysctl vfs.hirunningspace
determina quanto grande deve essere la coda I/O in tutti i controller
dei dischi nel sistema in un dato momento. Il valore predefinito in
genere è sufficiente ma su macchine con molti dischi
potreste voler aumentarlo a quattro o cinque
megabyte.
Notate che impostandolo ad un valore troppo alto (superando i limiti
della cache) potreste avere delle performance peggiori.
Non impostate un valore troppo alto arbitrariamente!
Valori più alti aumentano la latenza nelle letture
contemporanee.
Ci sono altre sysctl relative alla buffer-cache ed alle cache delle pagine VM. Non vi consigliamo di cambiare questi valori, il sistema di VM fa già un ottimo lavoro di messa a punto automatica.
La variabile sysctl vm.swap_idle_enabled
è utile in grossi sistemi multiutente dove si hanno molti
utenti che entrano ed escono lasciando molti processi inattivi.
Questi sistemi tendono a generare un grande pressione sulle riserve
di memoria libera. Attivando questa caratteristica e manipolando
l'isteresi di swap (in secondi di inattività) tramite
vm.swap_idle_threshold1
e
vm.swap_idle_threshold2
potete abbassare
la priorità delle pagine di memoria associate con i processi
inattivi più velocemente che con il normale algoritmo di
paginazione.
Ciò dà una mano al demone di paginazione. Non attivate
questa opzione a meno che non ne abbiate bisogno,
poichè il compromesso che state accettando è
essenzialmente di pre-paginare la memoria in anticipo piuttosto che
in ritardo, consumando dunque più
swap e banda di trasmissione verso il disco. In un piccolo sistema
questa opzione avrà un effetto ridotto
ma in un grosso sistema che è già sottoposto a un
moderato carico di paginazione questa opzione permette al sistema VM
di spostare facilmente interi processi dentro e fuori la
memoria.
FreeBSD 4.3 ha giocato un pò 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).
La configurazione del kernel SCSI_DELAY
può ridurre il tempo di avvio del sistema. I valori di default
sono piuttosto alti e possono essere responsabili
anche di 15
secondi di ritardo
nel processo di avvio. Ridurre il valore a 5
secondi funziona in molti casi (specialmente con i dispositivi
moderni). Nuove versioni di FreeBSD (5.0 e superiori) dovrebbero essere
in grado di usare kern.cam.scsi_delay
come un'opzione da boot. Quest'ultima e l'opzione di
configurazione del kernel accettano valori in
millisecondi , e
non in secondi.
Il programma tunefs(8) può essere usato per mettere a punto con accuratezza un file system. Questo programma ha molte opzioni differenti, ma per ora noi ci preoccuperemo solo di attivare e disattivare i Soft Update, che verrà effettuato tramite:
#
tunefs -n enable /filesystem
#
tunefs -n disable /filesystem
Un file system non potrà essere modificato con tunefs(8) mentre è montato. Un buon momento per attivare i Soft Update è prima che le partizioni siano montate, in modalità singolo utente.
I Soft Update migliorano drasticamente le prestazioni dei
meta-dati, principalmente la creazione e la cancellazione di file,
attraverso l'uso di una memoria cache. Consigliamo di attivare i Soft
Update su tutti i file system. Ci sono due lati negativi relativi ai
Soft Update dei quali dovresti essere a conoscenza: primo, i Soft
Update garantiscono la consistenza del file system in caso di crash ma
è più che probabile che passino molti secondi (anche un
minuto!) prima che venga aggiornato fisicamente il disco. Se il
sistema va in crash potresti perdere molto più lavoro in questo
modo. Secondo, i Soft Update rallentano la liberazione dei blocchi
liberi del file system. Se hai un file system (come il file system
root) che è quasi pieno, la realizzazione di un grosso
aggiornamento, come un make installworld
, potrebbe
essere causa di un superamento dei limiti di spazio del file system e
di un fallimento dell'aggiornamento.
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, tutte 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 Update: 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 in background 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 Update, 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.
Questo, ed altri documenti, possono essere scaricati da ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Per domande su FreeBSD, leggi la
documentazione prima di contattare
<questions@FreeBSD.org>.
Per domande su questa documentazione, invia una e-mail a
<doc@FreeBSD.org>.