Capitolo 11. Configurazione e Messa a Punto

Nel disegnare il tuo file system con bsdlabel(8) o sysinstall(8), ricorda che i dischi rigidi possono trasferire dati ad un ritmo maggiore dalle tracce esterne rispetto a quelle interne. Quindi i file system più piccoli e con un gran numero di accessi dovrebbero essere più vicini alla parte esterna del disco, mentre le partizioni più ampie, come /usr, dovrebbero essere posizionate verso l’interno. È una buona idea creare le partizioni in un ordine simile al seguente: root, swap, /var, /usr.

Le dimensioni della partizione /var riflettono l’uso che intendi fare della macchina. /var viene usata per mantenere le caselle di posta, i file di log, e gli spool della stampante. Le caselle di posta e file di log potrebbero crescere in maniera imprevedibile in relazione al numero di utenti presenti sul tuo sistema e da quanto a lungo manterrai i file di log. La maggior parte degli utenti non avrà mai bisogno di un gigabyte, ma ricorda che /var/tmp deve essere abbastanza ampia da contenere tutti i pacchetti.

La partizione /usr contiene molti dei file richiesti per far funzionare il sistema, la collezioni dei ports(7) (raccomandata) e il codice sorgente (opzionale). Entrambi sono opzionali al momento dell’installazione. Almeno 2 gigabyte sono raccomandati per questa partizione.

Quando decidi le dimensioni delle partizioni, tieni a mente le richieste di spazio. Esaurire lo spazio in una partizione mentre ne usi poco in un’altra può essere molto fastidioso.

Come regola generale, la partizione di swap dovrebbe essere tipicamente il doppio della quantità di memoria principale (RAM). Ad esempio, se la macchina avesse 128 megabyte di memoria, il file di swap dovrebbe essere di 256 megabyte. Sistemi con meno memoria potrebbero funzionare meglio con uno swap maggiore. Meno di 256 megabyte di swap non è raccomandato e dovresti pensare ad una espansione della memoria. Gli algoritmi di paginazione sono ottimizzati per funzionare al meglio quando la partizione di swap è almeno due volte la dimensione della memoria principale. Configurare uno swap troppo piccolo potrebbe portare ad una inefficienza nel codice di scansione della VM e potrebbe creare problemi in seguito, nel caso di aggiunta di memoria alla macchina.

Su sistemi più grandi con dischi SCSI multipli (o dischi IDE multipli collegati a diversi controller) è consigliabile che ci sia uno swap per ogni disco (fino a quattro dischi). Le partizioni di swap dovrebbero avere approssimativamente le stesse dimensioni. Il kernel può gestire dimensioni arbitrarie ma internamente le strutture dati scalano meglio fino a quattro volte la dimensione della partizione di swap più ampia. Avere partizioni di swap con dimensioni simili permetterà al kernel di distribuire al meglio lo spazio di swap tra i dischi. Partizioni di swap grandi vanno bene, anche se non vengono usate molto. Potrebbe essere più semplice recuperare il sistema da un programma impazzito prima di essere costretti a riavviare.

Molti utenti pensano che un’unica grande partizione vada bene, ma ci sono molte ragioni per cui questa è una cattiva idea. Primo, ogni partizione ha differenti caratteristiche operative e separarle permette ai file system di ottimizzare se stessi di conseguenza. Ad esempio, le partizioni root e /usr sono per lo più usate in lettura, senza molte operazioni di scrittura. Un sacco di letture e scritture potrebbero esserci in /var e /var/tmp.

Partizionando in maniera appropriata il sistema, la frammentazione introdotta nelle partizioni più piccole, con più carico in scrittura, non inciderà sulle partizioni per lo più di lettura. Mantenere le partizioni con maggiore carico in scrittura vicine al bordo del disco aumenterà le prestazioni di I/O nelle partizioni dove ne hai più bisogno. Ora, sebbene potresti avere bisogno di prestazioni di I/O anche nelle partizioni più ampie, spostarle verso il bordo del disco non porterebbe nessun miglioramento significativo delle prestazioni, al contrario dello spostamento di /var all’esterno. Infine, ci sono problemi riguardanti la sicurezza. Una piccola, simpatica partizione di root che è essenzialmente di sola lettura ha ottime possibilità di sopravvivere intatta a un brutto crash.

Sfortunatamente, ci sono ancora molti venditori di hardware che non forniscono specifiche dei loro driver alla comunità open source perchè ritengono che tale informazione sia un segreto commerciale. Conseguentemente, gli sviluppatori di FreeBSD e di altri sistemi operativi hanno due scelte: sviluppare i driver con un lungo ed arduo processo di reverse engineering o usare i driver binari disponibili per le piattaforme Microsoft® Windows®. La maggior parte degli sviluppatori, inclusi quelli coinvolti in FreeBSD, ha preso la seconda strada.

Grazie al contributo di Bill Paul (wpaul), a partire da FreeBSD 5.3-RELEASE c’è supporto "nativo" per Network Driver Interface Specification (NDIS). Il NDISulator di FreeBSD (anche noto come Progetto Evil) prende un driver binario per Windows® e sostanzialmente crea un inganno fingendo di eseguirlo in Windows®. Poichè il driver ndis(4) sta usando un binario Windows®, è usabile solo su sistemi i386™ e amd64.

Per usare il NDISulator, hai bisogno sostanzialmente di tre cose:

Localizza i file per la tua carta specifica. Generalmente, posso essere trovati nel CD incluso o sui siti web dei venditori. Nei seguenti esempi, useremo W32DRIVER.SYS e W32DRIVER.INF.

Il prossimo passo è compilare il binario del driver in un modulo caricabile dal kernel. Per fare questo, come root, usa ndisgen(8):

L’utility ndisgen(8) è interattiva e chiederà altre informazioni di cui necessita; produrrà un modulo del kernel nella presente directory che può essere caricato in questo modo:

In aggiunta al modulo del kernel generato, devi caricare i moduli ndis.ko e if_ndis.ko. Questo dovrebbe avvenire automaticamente quando uno carica un modulo che dipende da ndis(4). Se vuoi caricarli manualmente, usa il seguente comando:

Il primo comando carica il wrapper del driver miniport NDIS, il secondo carica l’interfaccia di rete in questione.

Ora controlla dmesg(8) per vedere se c’era qualche errore durante il caricamento. Se tutto è andato bene, dovresti ottenere dell’output che somiglia a questo:

D’ora in poi, puoi trattare il device ndis0 come ogni altra scheda di rete (ad esempio dc0).

Puoi configurare il sistema perché carichi il modulo NDIS al momento del boot nello stesso modo di ogni altro modulo. Per prima cosa, copia il modulo generato W32DRIVER.ko, nella directory /boot/modules. Quindi, aggiungi le seguenti linee a /boot/loader.conf:

Per verificare che una scheda Ethernet sia configurata correttamente, si devono provare due cose. Prima, effettuare un ping verso l’interfaccia stessa, e poi un ping verso un’altra macchina sulla LAN.

Prima proviamo l’interfaccia:

Ora dobbiamo effettuare un ping verso un’altra macchina della LAN:

Puoi usare il nome della macchina invece di 192.168.1.2 se hai sistemato il file /etc/hosts.

Risolvere i problemi delle varie configurazioni hardware e software è sempre una faticaccia, ma è una fatica che può essere diminuita controllando da subito le cose semplici. Avete collegato il cavo di rete? Avete configurato i servizi di rete? Avete configurato il firewall correttamente? La scheda di rete che state usando è supportata da FreeBSD? Controllate sempre le note sul vostro hardware prima di inviare un bug report. Aggiornate la vostra versione di FreeBSD all’ultima versione STABLE disponibile. Controllate gli archivi delle mailing list, o magari cercate su Internet.

Se la scheda funziona, ma le prestazioni sono scadenti, potrebbe esservi utile la lettura della pagina man tuning(7). Potreste anche verificare la vostra configurazione della rete, poichè una configurazione scorretta può essere la causa di connessioni lente.

Alcuni utenti riscontrano dei device timeouts, il che è normale per alcune schede. Se questi continuano, o se sono fastidiosi, potreste voler ricontrollare che non ci siano conflitti con altri dispositivi. Controllate due volte la connessione di rete. Forse dovreste procurarvi un’altra scheda.

Alcune volte, gli utenti notano alcuni errori watchdog timeout. La prima cosa da fare è controllare il cavo di rete. Alcune schede di rete richiedono uno slot PCI che supporti il Bus Mastering. Su alcune vecchie schede madri, ciò è permesso solo per uno slot PCI (tipicamente lo slot 0). Controllate la documentazione della scheda di rete e della scheda madre per determinare se possa essere quello il problema.

Messaggi No route to host vengono generati se il sistema non è in grado di effettuare il routing di un pacchetto verso una certa destinazione. Ciò può accadere se non è specificata una route di default, o se il cavo è scollegato. Controllate l’output di netstat -rn ed assicuratevi che ci sia una route valida per l’host che state cercando di raggiungere. Se non c’è, leggete il Networking Avanzato.

I messaggi d’errore ping: sendto: Permission denied sono spessi causati da un firewall mal configurato. Se ipfw è abilitato nel kernel ma non ci sono regole definite, allora la politica di default è di negare tutto il traffico, comprese le richieste di ping! Leggete il Firewall per maggiori informazioni.

Talvolta le prestazioni della scheda di rete sono scadenti, o sotto la media. In questi casi è preferibile cambiare la selezione del media da autoselect ad una selezione corretta. Anche se questo sistema funziona con la maggior parte dell’hardware, potrebbe non risolvere il problema per tutti. Ancora una volta, controllate tutte le impostazioni di rete, e leggete la pagina man tuning(7) .

/etc/resolv.conf detta il modo in cui il sistema di risoluzione dei nomi di FreeBSD accede al DNS (Internet Domain Name System).

I campi più comuni in resolv.conf sono:

Un resolv.conf tipico:

Se stai usando DHCP, dhclient(8) generalmente sovrascriverà resolv.conf con le informazioni ricevute dal server DHCP.

/etc/hosts è un semplice database testuale, reminiscenza della vecchia rete Internet. Esso lavora in congiunzione con DNS e NIS fornendo una mappatura da nome a indirizzo IP. Computer locali connessi ad una LAN possono essere messi in questo file per una gestione semplice dei nomi, invece di mettere su un server named(8). Inoltre, /etc/hosts può essere usato per fornire un registro locale dei nomi di Internet, riducendo la necessità di effettuare richieste esternamente per i nomi ad accesso frequente.

/etc/hosts accetta il semplicissimo formato:

Ad esempio:

Consulta hosts(5) per maggiori informazioni.

syslog.conf è il file di configurazione per il programma syslogd(8). Indica quale tipo di messaggi syslog verranno scritti su ogni file di log.

Consulta la pagina man di syslog.conf(5) per maggiori informazioni.

newsyslog.conf è il file di configurazione di newsyslog(8), un programma che normalmente viene eseguito da cron(8). newsyslog(8) determina quando i file di log richiedono un’archiviazione o un riordinamento. logfile viene rinominato in logfile.0, logfile.0 in logfile.1 e così via. Alternativamente, i file potranno essere archiviati in formato gzip(1), e quindi diventeranno: logfile.0.gz, logfile.1.gz, e così via.

newsyslog.conf indica quali file di log devono essere gestiti, quanti devono essere mantenuti, e quando devono essere toccati. I file di log possono essere riordinati e/o archiviati quando raggiungono una certa dimensione, o a una certa data/ora periodica.

Consulta la pagina man di newsyslog(8) per maggiori informazioni.

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.

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.

kern.maxfiles può essere aumentato o abbassato a seconda dei requisiti del tuo sistema. Questa variabile indica il numero massimo di descrittori di file sul tuo sistema. Quando la tabella dei descrittori di file è piena, apparirà ripetutamente la scritta file: table is full nel buffer dei messaggi di sistema, che può essere visualizzato con il comando dmesg.

Ogni file, socket, o fifo aperta usa un descrittore di file. Un server di produzione di larga scala può richiedere facilmente molte migliaia di descrittori di file, in relazione al tipo e al numero di servizi in esecuzione insieme.

Nelle vecchie release di FreeBSD, il valore predefinito di kern.maxfile viene dettato dall’opzione maxusers nel file di configurazione del kernel. kern.maxfiles cresce proporzionalmente al valore di maxusers. Quando si compila un kernel personalizzato, è una buona idea impostare questa opzione di configurazione del kernel in base agli usi del proprio sistema. Da questo numero, dipendono molti dei limiti predefiniti del kernel. Anche se una macchina in produzione potrebbe non avere effettivamente 256 utenti connessi contemporaneamente, le risorse necessarie potrebbero essere simili a quelle di un server web su larga scala.

A partire da FreeBSD 4.5, kern.maxusers è automaticamente dimensionato sulla base della memoria disponibile nel sistema, e può essere determinato a run-time leggendo il valore del sysctl read-only kern.maxusers. Alcuni siti richiedono valori minori o maggiori di kern.maxusers e questo può essere impostato come un parametro modificabile dal loader; valori di 64, 128 o 256 non sono fuori dal comune. Non raccomandiamo di andare oltre i 256 a meno che non si necessiti di un numero esagerato di file descriptor; molti dei valori modificati nel loro default da kern.maxusers possono essere singolarmente sovrascritti a boot-time o a run-time in /boot/loader.conf (leggi la pagina di manuale loader.conf(5) o il file /boot/defaults/loader.conf per alcuni suggerimenti) o come descritto altrove in questo documento. Sistemi precedenti a FreeBSD 4.4 devono invece impostare questo valore attraverso l’opzione di config(8) maxusers.

Nelle release precedenti, il sistema setterà in modo automatico maxusers se lo imposti a 0. Quando usi quest’opzione, impostalo almeno a 4, specialmente se stai usando il sistema a finestre X o se compili software. Questo è dovuto al fatto che la tabella più importante settata da maxusers è quella relativa al numero massimo di processi, risultato di 20 + 16 * maxusers, e quindi se setti maxusers a 1, puoi avere solo 36 processi in modo simultaneo, inclusi i 18 o più di avvio del sistema e i 15 o più che verranno creati all’avvio del sistema a finestre X. Perfino una semplice attività come la lettura di una pagina man avvia fino a 9 processi per filtrare, decomprimere, e visualizzare la pagina. Settando maxusers a 64 avrai fino a 1044 processi simultanei, che dovrebbero essere sufficienti per quasi tutti gli utenti. Ad ogni modo, se vedi il temuto errore quando tenti di avviare un programma, o se stai usando un server con molti utenti simultanei (come ftp.FreeBSD.org), puoi sempre incrementare il numero e ricompilare.

La variabile sysctl kern.ipc.somaxconn limita la dimensione della coda in ascolto per le connessioni TCP. Il valore predefinito è di 128, generalmente troppo basso per una gestione robusta di nuove connessioni in ambienti come i web server molto carichi. Per tali ambienti, è consigliato aumentare questo valore a 1024 o maggiore. Il demone di servizio può a sua volta limitare la dimensione della coda (e.g. sendmail(8), o Apache) ma spesso avrà una direttiva nel proprio file di configurazione per correggere la dimensione della coda. Grosse code di ascolto aiutano anche ad evitare attacchi di tipo Denial of Service ().

La variabili sysctl net.inet.ip.portrange.* controllano i numeri di porta automaticamente assegnate a socket TCP ed UDP. Ci sono tre intervalli: uno basso, uno predefinito, ed uno alto. La maggior parte dei programmi usa l’intervallo predefinito che è controllato da net.inet.ip.portrange.first e net.inet.ip.portrange.last, che hanno valori predefiniti di 1024 e 5000. Questi intervalli sono usati per le connessioni in uscita, ed è possibile che il sistema esaurisca le porte in alcune circostanze. Ciò accade per lo più quando avete un web proxy molto carico. L’intervallo di porte non è un problema quando si usano server che abbiano per lo più connessioni in ingresso, come i normali web server, o un numero limitato di connessioni in uscita, come i relay di posta. Per situazioni nelle quali potreste terminare le porte, è consigliato aumentare leggermente net.inet.ip.portrange.last. Un valore di 10000, 20000 o 30000 può essere ragionevole. Dovreste anche considerare gli effetti relativi ad un firewall nel cambiare il range di porte. Alcuni firewall potrebbero bloccare grandi intervalli di porte (tipicamente le porte basse) ed aspettarsi che i sistemi usino porte più alte per le connessioni in uscita - per questa ragione si consiglia di non abbassare il valore di net.inet.ip.portrange.first.

Il limite del Prodotto del Ritardo di Banda TCP è simile a TCP/Vegas in NetBSD. Può essere abilitato impostando la variabile sysctl net.inet.tcp.inflight_enable ad 1. Il sistema tenterà di calcolare il prodotto del ritardo di banda per ogni connessione e limiterà l’ammontare di dati accodati per la trasmissione su rete al livello migliore per garantire il massimo throughput.

Questa funzionalità è utile quando si inviano dati su modem multipli, su Ethernet Gigabit, o su collegamenti WAN ad alta velocità (o qualsiasi altro collegamento con un alto prodotto a banda di ritardo), in particolar modo se state usando anche il window scaling o se avete configurato una finestra TCP molto ampia. Se abilitate questa opzione, dovreste anche assicurarvi di impostare a 0 net.inet.tcp.inflight_debug (per disabilitare il debugging), e per un uso di produzione può essere utile impostare net.inet.tcp.inflight_min ad almeno 6144. Notate comunque che impostando dei livelli minimi alti può in pratica disabilitare la limitazione di banda, su alcuni tipi di collegamento. La funzionalità di limitazione della banda riduce la quantità di dati creati in rotte intermedie e fa circolare le code di pacchetti così come riduce la quantità di dati creati nella coda di interfaccia dell’host locale. Con meno pacchetti accodati, le connessioni interattive, specialmente sopra modem lenti, opereranno con lenti Round Trip Times (tempi di andata e ritorno). Comunque, nota che questa feature ha effetto solo sulla trasmissione dati (uploading / lato server). Non ha effetto sulla ricezione (downloading).

Modificare net.inet.tcp.inflight.stab non è raccomandato. Questo parametro è di default a 20, rappresentando 2 pacchetti massimi aggiunti al ritardo del prodotto della banda della finestra. La finestra addizionale è richiesta per stabilizzare l’algoritmo e migliorare la risposta alle condizioni che cambiano ma può risultare in tempi lunghi sui ping sopra link lenti (anche se molto più lento di quello che otterresti senza l’algoritmo di inflight). In questi casi, puoi voler ridurre questo parametro a 15, 10 o 5; e puoi anche ridurre net.inet.tcp.inflight.min (per esempio, a 3500) per ottenere l’effetto desiderato. Ridurre questi parametri dovrebbe essere fatto solo come ultima spiaggia.

Un vnode è la rappresentazione di un file o una directory. Aumentare il numero di vnodi disponibili sul sistema operativo aumenterà l’I/O di disco. Normalmente questo viene gestito dal sistema operativo e non deve essere cambiato. In pochi casi dove l’I/O di disco è un collo di bottiglia ed il sistema sta finendo i suoi vnodi, questo parametro sarà aumentato. L’aumento di RAM libera ed inattiva sarà tenuto in conto.

Per vedere il numero corrente di vnodi in uso:

Per vedere il numero massimo di vnodi:

Se l’uso del nodo corrente è vicino alla fine, aumentare kern.maxvnodes di un valore di 1.000 è probabilmente una buona idea. Tenete un occhio sul numero di vfs.numvnodes. Se scala al massimo, kern.maxvnodes dovrà essere incrementato ancora. Dovrebbe essere visibile con top(1) uno spostamento nell’uso della memoria. Molta memoria dovrebbe essere attiva.

In alcuni casi, ripartire dopo una operazione di sospensione, fa sì che il mouse non riparta. Un noto workaround è aggiungere hint.psm.0.flags="0x3000" al file /boot/loader.conf. Se questo non funziona allora per favore considera l’invio di un report del baco come descritto in precedenza.

ACPI ha tre stati di sospensione RAM (STR), S1-S3 ed un stato di sospensione disco (STD), chiamato S4. S5 è il "soft off" ed è il normale stato in cui il tuo sistema si trova quando è collegato ma non acceso. S4 può essere implementato in due modi separati. S4BIOS è una sospensione BIOS-assistita da disco. S4OS è implementato direttamente dal sistema operativo.

Inizia a controllare sysctl hw.acpi per le entry relative alla sospensione. Questi sono i risultati per un Thinkpad:

Questo significa che possiamo usare acpiconf -s per testare S3, S4OS, S5. Se s4bios fosse stato uno (1), avremmo supporto a S4BIOS invece di S4OS.

Quando si testa la sospensione/riavvio, inizia con S1, se supportato. È più probabile che funzioni questo stato dato che non richiede molto supporto dal driver. Nessuno ha implementato S2, ma se tu lo hai, è simile a S1. La prossima cosa da provare è S3. Questo è lo stato più profondo STR e richiede molto supporto dal driver per reinizializzare il tuo hardware. Se hai problemi a riavviarlo, sentiti libero di segnalarlo via mail alla lista mailing list su ACPI in FreeBSD ma non aspettarti che il problema sia risolto dato che ci sono molti driver/hardware che hanno bisogno di test e di lavoro aggiuntivo.

Per aiutare ad isolare il problema, rimuovi quanti più driver possibile dal tuo kernel. Se funziona, puoi scoprire quale driver causa il problema caricando dei driver fino a che il problema si ripresenta. Tipicamente i driver binari come nvidia.ko, i driver di display di X11, e USB avranno la maggior parte dei problemi mentre interfacce Ethernet funzioneranno bene. Se puoi caricare/scaricare driver correttamente, puoi automatizzare questo piazzando i comandi appropriati in /etc/rc.suspend e /etc/rc.resume. C’è un esempio commentato su come caricare e scaricare un driver. Prova a impostare hw.acpi.reset_video a zero (0) se il tuo display è confuso dopo il riavvio. Prova a impostare valori più lunghi o corti per hw.acpi.sleep_delay per vedere se aiuta.

Un’altra cosa da provare è caricare una distribuzione Linux recente con supporto ACPI e testare il loro supporto sospensione/riavvio sullo stesso hardware. Se funziona su Linux, è probabile che sia un problema driver relativo a FreeBSD e restringere il campo di indagine su quale driver causi il problema può aiutare a risolvere il problema. Notate che i manutentori di ACPI non mantengono altri driver (ad esempio suono, ATA, etc.) così ogni lavoro fatto sull’identificazione del problema del driver dovrebbe alla fine essere risolto dalla lista mailing list su FreeBSD-CURRENT e inviato via mail al manutentore del driver. Se ti senti avventuroso, vai avanti e inizia a porre qualche printf(3) in un driver che dà problemi per tracciare in quale driver nella sua funzione di resume vada in palla.

Alla fine, cerca di disabilitare ACPI ed ad abilitare APM invece. Se la sospensione ed il riavvio funziona con APM, è meglio che tu continui con APM, specialmente su hardware vecchio (pre-2000). Ci vuole un pò di tempo per i venditori per ottenere un supporto corretto all’ACPI e l’hardware più vecchio è più probabile che abbia problemi BIOS con ACPI.

La maggior parte dei blocchisono causati da interrupt persi o da una tempesta di interrupt. I chipset hanno un sacco di problemi su come il BIOS configuri gli interrupt prima del boot, la correttezza delle tabelle ACPI (MADT) ed il routing del System Control Interrupt (SCI).

Le tempeste di interrupt possono essere distinte da interrupt persi controllando l’output di vmstat -i e guardando alla linea che riguarda acpi0. Se il contatore sta avanzando più di un paio di secondi per volta, hai una tempesta di interrupt. Se il sistema si blocca, cerca di di entrare in DDB (CTRL+ALT+ESC sulla console) e digita show interrupts.

Il modo migliore in caso di problemi di interrupt è provare a disabilitare il supporto APIC con hint.apic.0.disabled="1" in loader.conf.

I panici sono relativamente rari per ACPI e sono il primo problema ad essere corretto. Il primo passo da fare è riprodurre il panico (se possibile) ed ottenere un backtrace. Segui l’avvertimento per abilitare options DDB e imposta una console seriale (vedi la Accesso al Debugger DDB dalla Linea Seriale) o imposta una partizione di dump(8). Puoi ottenere un backtrace in DDB con tr. Se hai scritto a mano il backtrace, accertati di ottenere le ultime cinque (5) e le prime cinque (5) linee nella traccia.

Poi, prova ad isolare il problema facendo boot con ACPI disabilitato. Se funziona, puoi isolare il sottosistema ACPI usando vari valori di debug.acpi.disable. Leggi la pagina di manuale di acpi(4) per alcuni esempi.

Prima, cerca di impostare hw.acpi.disable_on_poweroff="0" in loader.conf(5). Questo fa sì che ACPI abbia disabilitato alcuni eventi durante il processo di shutdown. Alcuni sistemi hanno bisogno di impostare questo valore a 1 (il default) per la stessa ragione. Questo di solito aggiusta il problema di un sistema che si accende spontaneamente dopo una sospensione o uno spegnimento.

Se hai altri problemi con ACPI (lavorare con un docking station, dispositivi non trovati, ecc.), per favore invia via mail una descrizione anche alla mailing list; comunque, alcune di queste questioni possono essere correlate a parti del sottosistema ACPI così può volerci un pò prima che siano implementate. Per favore sii paziente e preparato a testare le patch che ti vengono inviate.

Alcuni AML assumono che il mondo consiste di varie versioni Windows®. Puoi far sì che FreeBSD simuli qualsiasi OS per vedere se questo risolve il problema che hai. Un modo facile per sovrascrivere questo è porre hw.acpi.osname="Windows 2001" in /boot/loader.conf o altre stringhe simili che trovi nella ASL.

Alcuni metodi non ritornano esplicitamente un valore come i requisiti standard. Mentre ACPI-CA non gestisce questo, FreeBSD ha un workaround che permette di ritornare i valori implicitamente. Puoi anche aggiungere espliciti Valori di Ritorno dove si richiede se sai quale valore dovrebbe essere ritornato. Per forzare iasl a compilare l’ASL usa il flag -f.

Dopo che personalizzi il tuo your.asl, potresti volerlo compilare, esegui:

Puoi aggiungere il flag -f per forzare la creazione dell’AML, anche se ci sono errori durante la compilazione. Ricorda che alcuni errori (ad esempio valori di Ritorno mancanti) sono automaticamente riaggiustati dall’interprete.

DSDT.aml è il nome del file di default del comando iasl. Puoi caricare questo invece della copia difettosa del tuo BIOS (che è ancora presente in memoria) editando il file /boot/loader.conf come segue:

Assicurati di copiare il tuo file DSDT.aml nella directory /boot.