Κεφάλαιο 12. Ρύθμιση και Βελτιστοποίηση

Όταν δημιουργείτε συστήματα αρχείων με το bsdlabel(8) ή το sysinstall(8), θυμηθείτε ότι οι σκληροί δίσκοι μεταφέρουν δεδομένα γρηγορότερα απο τα εξωτερικά μέροι τους στα εσωτερικά. Έτσι μικρότερα και περισσότερο προσβάσιμα συστήματα αρχείων πρέπει να είναι πλησιέστερα στο εξωτερικό του δίσκου, ενώ μεγαλύτερες κατατμήσεις όπως το /usr πρέπει να τοποθετούνται πιο κοντά στο εσωτερικό του δίσκου. Είναι καλή ιδέα να δημιουργείτε κατατμήσεις με παρόμοια σειρά με αυτήν: root, swap, /var, /usr.

Το μέγεθος του /var αντανακλά την επιδιωκούμενη χρήση του μηχανήματος. Το /var χρησιμοποιείτε για την αποθήκευση των γραμματοκιβωτίων, των αρχείων καταγραφής και του spooler του εκτυπωτή. Τα γραμματοκιβώτια και τα αρχεία καταγραφής μπορούν να μεγαλώσουν σε απροσδόκητα μεγέθη ανάλογα με τον αριθμό των χρηστών του συστήματος και το χρονικό διάστημα που κρατούνται τα αρχεία καταγραφής. Σπάνια χρειάζεται το /var/tmp να έχει πάνω από ένα gigabyte χώρο, αλλά καλό είναι να έχετε κατά νου ότι πρέπει να είναι αρκετά μεγάλο για να κρατάει τα πακέτα που θέλετε να εγκαταστήσετε.

Η κατάτμηση /usr περιέχει τα περισσότερα αρχεία που απαιτούνται για την υποστήριξη του συστήματος, τη συλλογή των ports(7) (προτείνεται) και τον πηγαίο κώδικα (προαιρετικό). Και τα δύο αυτά είναι προαιρετικά κατα την εγκατάσταση. Τουλάχιστον 2 gigabytes προτείνονται για αυτή την κατάτμηση.

Όταν επιλέγετε μέγεθος για τις κατατμήσεις, να έχετε υπόψιν σας τις απαιτήσεις σε χώρο. Μπορεί να είναι λίγο πρόβλημα το να μείνετε χωρίς χώρο σε μια κατάτμηση ενώ χρησιμοποιείτε ελάχιστα μια άλλη.

Ένας εμπειρικός κανόνας για να επιλέξετε μέγεθος για την κατάτμηση swap είναι: πρέπει να είναι περίπου διπλή απο το μέγεθος της μνήμης (RAM) του συστήματος. Για παράδειγμα, αν το μηχάνημα έχει 128 megabytes μνήμης, η κατάτμηση swap πρέπει να είναι 256 megabytes. Συστήματα με λιγότερη μνήμη μπορούν να αποδίδουν καλύτερα με περισσότερο swap. Λιγότερο απο 256 megabytes swap δεν προτείνεται και πρέπει να εξεταστεί η επέκταση της μνήμης. Οι αλγόριθμοι VM paging του πυρήνα είναι έτσι φτιαγμένοι ώστε να αποδίδουν καλύτερα όταν η κατάτμηση swap είναι τουλάχιστον δύο φορές το μέγεθος της κεντρικής μνήμης. Αν ρυθμίσετε πολύ μικρό swap, μπορεί να έχουν μειωμένη απόδοση οι αλγόριθμοι σάρωσης σελίδων του υποσυστήματος VM και μπορεί αργότερα να δημιουργηθούν προβλήματα αν προστεθεί περισσότερη φυσική μνήμη.

Σε μεγαλύτερα συστήματα με πολλαπλούς SCSI δίσκους (ή πολλαπλούς IDE δίσκους σε διαφορετικούς ελεγκτές), είναι προτιμότερο το swap να είναι ρυθμισμένο σε κάθε δίσκο (μέχρι τέσσερις δίσκους). Οι ξεχωριστές κατατμήσεις swap καλό είναι να έχουν περίπου το ίδιο μέγεθος. Ο πυρήνας μπορεί να χειριστεί αυθαίρετα μεγέθη swap, αλλά οι εσωτερικές δομές δεδομένων ρυθμίζονται με βάση το μέγεθος της μεγαλύτερης κατάτμησης swap. Κρατώντας την κατάτμηση swap σχεδόν στο ίδιο μέγεθος θα επιτρέψει στον πυρήνα να βελτιστοποιήσει την χρήση του swap, μοιράζοντας πιο καλά το φόρτο σε κάθε δίσκο. Δεν πειράζει να έχετε μεγάλο μέγεθος swap, ακόμα και αν δε χρησιμοποιείται αρκετά. Μπορεί να είναι ευκολότερη η ανάκαμψη απο ένα εκτός ελέγχου πρόγραμμα προτού χρειαστεί να επανεκκινήσετε το σύστημα.

Αρκετοί χρήστες νομίζουν ότι μία μεγάλη κατάτμηση θα είναι εντάξει, αλλά υπάρχουν αρκετοί λόγοι γιατί αυτό είναι κακή ιδέα. Καταρχήν, κάθε κατάτμηση έχει διαφορετικά λειτουργικά χαρακτηριστικά, οπότε ξεχωρίζοντας τις κατατμήσεις επιτρέπουμε στο σύστημα αρχείων να εναρμονίζεται ανάλογα. Για παράδειγμα, οι root και /usr κατατμήσεις είναι κυρίως για ανάγνωση, χωρίς πολλές εγγραφές. Αντίθετα, γίνονται πολλές αναγνώσεις και εγγραφές στις /var και /var/tmp.

Κάνοντας σωστή κατάτμηση σε ένα σύστημα, ο κατακερματισμός που συμβαίνει σε μικρότερες και περισσότερο εγγράψιμες κατατμήσεις δεν θα διαρρεύσει στις κατατμήσεις που διαβάζονται πιο συχνά από ότι γράφονται. Κρατώντας τις περισσότερο εγγράψιμες κατατμήσεις πιο κοντά στην άκρη του δίσκου, θα αυξηθεί η I/O απόδοση στις κατατμήσεις όπου και χρειάζεται πιο συχνά. Τώρα ενώ η απόδοση I/O χρειάζεται στις μεγαλύτερες κατατμήσεις, αλλάζοντας αυτές πιο κοντά στην άκρη του δίσκου δεν θα οδηγήσει σε σημαντική αύξηση της απόδοσης όσο το να μετακινήσετε την /var στην άκρη. Τέλος, υπάρχει και θέμα ασφάλειας. Μία μικρή, προσεγμένη root κατάτμηση η οποία είναι διαβάζεται πιο συχνά από ότι γράφεται έχει μεγαλύτερη πιθανότητα να επιζήσει ενός άσχημου χτυπήματος.

Δυστυχώς, υπάρχουν ακόμα πολλοί κατασκευαστές που δεν παρέχουν τεχνικές προδιαγραφές για τους οδηγούς τους στην κοινότητα του ανοικτού λογισμικού γιατί αντιμετωπίζουν τέτοιες πληροφορίες σαν μυστικά του εμπορίου. Συνεπώς, οι υπεύθυνοι για την ανάπτυξη του FreeBSD και άλλων λειτουργικών συστημάτων μένουν με δύο επιλογές: να αναπτύξουν οδηγούς με την μακρά και επίπονη διαδικασία της αντίστροφης μηχανικής ή να χρησιμοποιήσουν ήδη υπάρχοντες οδηγούς σε δυαδική μορφή διαθέσιμους για την πλατφόρμα Microsoft® Windows®. Οι περισσότεροι υπεύθυνοι για την ανάπτυξη, μεταξύ τους και αυτοί που εμπλέκονται με το FreeBSD, έχουν επιλέξει την δεύτερη προσέγγιση.

Χάρη την προσφορά του Bill Paul (wpaul), μιάς και απο το FreeBSD 5.3-RELEASE υπάρχει "γηγενής" υποστήριξη για το Network Driver Interface Specification (NDIS). Το έργο FreeBSD NDISulator (διαφορετικά γνωστό σας Project Evil) παίρνει έναν οδηγό Windows® σε δυαδική μορφή και στην ουσία τον εξαπατά ώστε να νομίζει ότι τρέχει σε Windows®. Λόγο του ότι ο οδηγός ndis(4) χρησιμοποιεί μία Windows® δυαδική μορφή, μπορεί να χρησιμοποιηθεί μόνο σε i386™ και amd64 συστήματα.

Για να χρησιμοποιήσετε τον NDISulator, θα χρειαστείτε τρία πράγματα:

Εντοπίστε τα αρχεία αυτά για την κάρτα σας. Γενικά, αυτά μπορούν να βρεθούν στα παρεχόμενα CDs ή στους ιστότοπους των κατασκευαστών. Στα ακόλουθα παραδείγματα, θα χρησιμοποιήσουμε τα αρχεία W32DRIVER.SYS και W32DRIVER.INF.

Το επόμενο βήμα είναι να μεταγλωττίσετε τον δυαδικό οδηγό μέσα σε ένα φορτώσιμο άρθρωμα του πυρήνα. Για να το επιτύχετε αυτό, θα πρέπει σαν root, να χρησιμοποιήσετε το ndisgen(8):

Το βοηθητικό πρόγραμμα ndisgen(8) είναι διαδραστικό και θα σας ενημερώσει για οποιαδήποτε επιπλέον πληροφορία μπορεί να χρειαστεί; θα παράγει ένα άρθρωμα του πυρήνα στον τρέχωντα κατάλογο και μπορεί να φορτωθεί ως εξής:

Επιπλέον του παραχθέντος αρθρώματος, θα πρέπει να φορτώσετε τα αρθρώματα ndis.ko και if_ndis.ko. Αυτό θα πρέπει να γίνει αυτόματα όταν φορτώνετε οποιαδήποτε εξαρτάται απο το ndis(4). Αν θέλετε να το κάνετε χειρωνακτικά, θα πρέπει να χρησιμοποιήσετε τις ακόλουθες εντολές:

Η πρώτη εντολή φορτώνει τον οδηγό NDIS miniport wrapper, ενώ η δεύτερη φορτώνει την πραγματική κάρτα δικτύου.

Τώρα, ελέγξτε το dmesg(8) για να δείτε αν υπάρχουν σφάλματα κατα την φόρτωση. Αν όλα πήγαν καλά, θα πρέπει να δείτε μια παρόμοια έξοδο με την επόμενη:

Απο εδώ και πέρα μπορείτε να χειριστείτε την συσκευή ndis0 σαν μια οποιαδήποτε κάρτα δικτύου (π.χ., dc0).

Μπορείτε να ρυθμίσετε το σύστημα να φορτώνει τα NDIS αρθρώματα κατα την εκκίνηση με τον ίδιο τρόπο με τα όπως με οποιαδήποτε άλλα αρθρώματα. Πρώτα, αντιγράψτε το παραχθείσα άρθρωμα, W32DRIVER.ko, στον κατάλογο /boot/modules. Τότε, προσθέστε την ακόλουθη γραμμή στο /boot/loader.conf:

Για να επιβεβαιώσετε ότι η Ethernet κάρτα λειτουργεί σωστά, θα πρέπει να κάνετε δύο πράγματα. Πρώτα, κάντε ping την κάρτα την ίδια, και μετά κάντε ping ένα άλλο μηχάνημα στο LAN.

Πρώτα δοκιμάστε στην τοπική κάρτα:

Τώρα δοκιμάστε σε ένα άλλο μηχάνημα στο LAN:

Μπορείτε να χρησιμοποιήσετε και το όνομα το μηχανήματος αντί της διεύθυνσης 192.168.1.2 αν έχετε ρυθμίσει το αρχείο /etc/hosts.

Η επίλυση προβλημάτων υλικού και λογισμικού είναι πάντοτε επίπονη, ένας πόνος ο οποιός μπορεί να ανακουφιστεί ελέγχοντας μερικά απλά πράγματα πρώτα. Είναι το καλώδιο του δικτύου συνδεδεμένο; Έχετε ρυθμίσει σωστά τις υπηρεσίες δικτύου; Έχετε ρυθμίσει σωστά το πύρινο τείχος; Έχει πράγματι το FreeBSD υποστήριξη για αυτή την κάρτα δικτύου; Πρέπει πάντα να ελέγχετε τις σημειώσεις του υλικού πριν στείλε μία αναφορά για ένα πρόβλημα. Αναβαθμίστε την έκδοση του FreeBSD στην τελευταία ΣΤΑΘΕΡΗ έκδοση. Ελέγξτε τα αρχεία των λιστών μηνυμάτων, ή ψάξτε στο Internet.

Αν η κάρτα δουλεύει, αλλά με χαμηλή απόδοση, θα άξιζε να διαβάσετε την σελίδα βοηθείας tuning(7). Μπορείτε επίσης να ελέγξετε οι αν λανθασμένες ρυθμίσεις του δικτύου προκαλούν τις αργές συνδέσεις.

Μερικοί χρήστες αντιμετωπίζουν ένα ή δύο μηνύματα device timeout, τα οποία είναι φυσιολογικά για μερικές κάρτες. Αν συνεχιστούν, ή γίνουν ενοχλητικά, θα πρέπει να ελέγξετε μήπως και κάποιες συσκευές παρεμποδίζουν η μία την άλλη. Ελέγξτε διπλά τις συνδέσεις των καλωδίων. Ίσως θα πρέπει να αποκτήσετε μία άλλη κάρτα.

Μερικές φορές, οι χρήστες παρατηρούν μερικά μηνύματα λάθους watchdog timeout. Το πρώτο πράγμα που πρέπει να κάνετε είναι να ελέγξετε το καλώδιο του δικτύου. Αρκέτες κάρτες χρειάζονται μία θέση PCI που να υποστηρίζει Bus Mastering. Σε μερικές παλιές μητρικές κάρτες. μόνο μία θέση PCI το υποστήριζε (συνήθως η θέση 0). Ελέγξτε την κάρτα δικτύου και την τεκμηρίωση της μητρικής κάρτας για να διαπιστώσετε αν εκεί είναι το πρόβλημα.

Το μήνυμα No route to host εμφανίζεται αν το σύστημα αδυνατεί να δρομολογήσει τα πακέτα στον προορισμό τους. Αυτό συμβαίνει αν δεν έχει καθοριστεί προεπιλεγμένη διεύθυνση δρομολόγησης, ή αν ένα καλώδιο έχει ξεσυνδεθεί. Ελέγξτε την έξοδο τις εντολής netstat -rn και σιγουρευτείτε ότι η διεύθυνση δρομολόγησης είναι έγκυρη. Αν δεν έχει καθοριστεί, διαβάστε το Προχωρημένα Θέματα Δικτύωσης για περισσότερες πληροφορίες.

Το μήνυμα λάθους ping: sendto: Permission denied συμβαίνει κυρίως λόγο κάποιας λάθος ρύθμισης στο πύρινο τείχος. Αν το ipfw είναι ενεργοποιημένο στον πυρήνα αλλά δεν έχουν καθοριστεί κανόνες, τότε η προεπιλεγμένη πολιτική είναι η απαγόρευση όλης της κίνησης, ακόμα και των αιτημάτων ping! Διαβάστε το Firewalls για περισσότερες πληροφορίες.

Μερικές φορές η απόδοση της κάρτας μπορεί να είναι φτωχή, ή κάτω του μέσου όρου. Σε αυτές τις περιπτώσεις το καλύτερο είναι να ρυθμίσετε την κατάσταση του μέσου απο autoselect στην κατάλληλη κατάσταση. Ενώ συνήθως αυτό φαίνετε να δουλεύει στα περισσότερα υλικά, μπορεί να μην λύσει το πρόβλημα στον καθέναν. Και πάλι, ελέγξτε όλες τις ρυθμίσεις του δικτύου, και ξαναδιαβάστε πάλι την σελίδα βοηθείας tuning(7).

/etc/resolv.conf dictates how FreeBSD’s resolver accesses the Internet Domain Name System (DNS).

The most common entries to resolv.conf are:

A typical resolv.conf:

If you are using DHCP, dhclient(8) usually rewrites resolv.conf with information received from the DHCP server.

/etc/hosts is a simple text database reminiscent of the old Internet. It works in conjunction with DNS and NIS providing name to IP address mappings. Local computers connected via a LAN can be placed in here for simplistic naming purposes instead of setting up a named(8) server. Additionally, /etc/hosts can be used to provide a local record of Internet names, reducing the need to query externally for commonly accessed names.

/etc/hosts takes on the simple format of:

For example:

Consult hosts(5) for more information.

syslog.conf is the configuration file for the syslogd(8) program. It indicates which types of syslog messages are logged to particular log files.

Consult the syslog.conf(5) manual page for more information.

newsyslog.conf is the configuration file for newsyslog(8), a program that is normally scheduled to run by cron(8). newsyslog(8) determines when log files require archiving or rearranging. logfile is moved to logfile.0, logfile.0 is moved to logfile.1, and so on. Alternatively, the log files may be archived in gzip(1) format causing them to be named: logfile.0.gz, logfile.1.gz, and so on.

newsyslog.conf indicates which log files are to be managed, how many are to be kept, and when they are to be touched. Log files can be rearranged and/or archived when they have either reached a certain size, or at a certain periodic time/date.

Consult the newsyslog(8) manual page for more information.

The vfs.vmiodirenable sysctl variable may be set to either 0 (off) or 1 (on); it is 1 by default. This variable controls how directories are cached by the system. Most directories are small, using just a single fragment (typically 1 K) in the file system and less (typically 512 bytes) in the buffer cache. With this variable turned off (to 0), the buffer cache will only cache a fixed number of directories even if you have a huge amount of memory. When turned on (to 1), this sysctl allows the buffer cache to use the VM Page Cache to cache the directories, making all the memory available for caching directories. However, the minimum in-core memory used to cache a directory is the physical page size (typically 4 K) rather than 512 bytes. We recommend keeping this option on if you are running any services which manipulate large numbers of files. Such services can include web caches, large mail systems, and news systems. Keeping this option on will generally not reduce performance even with the wasted memory but you should experiment to find out.

The vfs.write_behind sysctl variable defaults to 1 (on). This tells the file system to issue media writes as full clusters are collected, which typically occurs when writing large sequential files. The idea is to avoid saturating the buffer cache with dirty buffers when it would not benefit I/O performance. However, this may stall processes and under certain circumstances you may wish to turn it off.

The vfs.hirunningspace sysctl variable determines how much outstanding write I/O may be queued to disk controllers system-wide at any given instance. The default is usually sufficient but on machines with lots of disks you may want to bump it up to four or five megabytes. Note that setting too high a value (exceeding the buffer cache’s write threshold) can lead to extremely bad clustering performance. Do not set this value arbitrarily high! Higher write values may add latency to reads occurring at the same time.

There are various other buffer-cache and VM page cache related sysctls. We do not recommend modifying these values, the VM system does an extremely good job of automatically tuning itself.

The vm.swap_idle_enabled sysctl variable is useful in large multi-user systems where you have lots of users entering and leaving the system and lots of idle processes. Such systems tend to generate a great deal of continuous pressure on free memory reserves. Turning this feature on and tweaking the swapout hysteresis (in idle seconds) via vm.swap_idle_threshold1 and vm.swap_idle_threshold2 allows you to depress the priority of memory pages associated with idle processes more quickly then the normal pageout algorithm. This gives a helping hand to the pageout daemon. Do not turn this option on unless you need it, because the tradeoff you are making is essentially pre-page memory sooner rather than later; thus eating more swap and disk bandwidth. In a small system this option will have a determinable effect but in a large system that is already doing moderate paging this option allows the VM system to stage whole processes into and out of memory easily.

FreeBSD 4.3 flirted with turning off IDE write caching. This reduced write bandwidth to IDE disks but was considered necessary due to serious data consistency issues introduced by hard drive vendors. The problem is that IDE drives lie about when a write completes. With IDE write caching turned on, IDE hard drives not only write data to disk out of order, but will sometimes delay writing some blocks indefinitely when under heavy disk loads. A crash or power failure may cause serious file system corruption. FreeBSD’s default was changed to be safe. Unfortunately, the result was such a huge performance loss that we changed write caching back to on by default after the release. You should check the default on your system by observing the hw.ata.wc sysctl variable. If IDE write caching is turned off, you can turn it back on by setting the kernel variable back to 1. This must be done from the boot loader at boot time. Attempting to do it after the kernel boots will have no effect.

For more information, please see ata(4).

The SCSI_DELAY kernel config may be used to reduce system boot times. The defaults are fairly high and can be responsible for 15 seconds of delay in the boot process. Reducing it to 5 seconds usually works (especially with modern drives). Newer versions of FreeBSD (5.0 and higher) should use the kern.cam.scsi_delay boot time tunable. The tunable, and kernel config option accept values in terms of milliseconds and not seconds.

There are two traditional approaches to writing a file systems meta-data back to disk. (Meta-data updates are updates to non-content data like inodes or directories.)

Historically, the default behavior was to write out meta-data updates synchronously. If a directory had been changed, the system waited until the change was actually written to disk. The file data buffers (file contents) were passed through the buffer cache and backed up to disk later on asynchronously. The advantage of this implementation is that it operates safely. If there is a failure during an update, the meta-data are always in a consistent state. A file is either created completely or not at all. If the data blocks of a file did not find their way out of the buffer cache onto the disk by the time of the crash, fsck(8) is able to recognize this and repair the filesystem by setting the file length to 0. Additionally, the implementation is clear and simple. The disadvantage is that meta-data changes are slow. An rm -r, for instance, touches all the files in a directory sequentially, but each directory change (deletion of a file) will be written synchronously to the disk. This includes updates to the directory itself, to the inode table, and possibly to indirect blocks allocated by the file. Similar considerations apply for unrolling large hierarchies (tar -x).

The second case is asynchronous meta-data updates. This is the default for Linux/ext2fs and mount -o async for *BSD ufs. All meta-data updates are simply being passed through the buffer cache too, that is, they will be intermixed with the updates of the file content data. The advantage of this implementation is there is no need to wait until each meta-data update has been written to disk, so all operations which cause huge amounts of meta-data updates work much faster than in the synchronous case. Also, the implementation is still clear and simple, so there is a low risk for bugs creeping into the code. The disadvantage is that there is no guarantee at all for a consistent state of the filesystem. If there is a failure during an operation that updated large amounts of meta-data (like a power failure, or someone pressing the reset button), the filesystem will be left in an unpredictable state. There is no opportunity to examine the state of the filesystem when the system comes up again; the data blocks of a file could already have been written to the disk while the updates of the inode table or the associated directory were not. It is actually impossible to implement a fsck which is able to clean up the resulting chaos (because the necessary information is not available on the disk). If the filesystem has been damaged beyond repair, the only choice is to use newfs(8) on it and restore it from backup.

The usual solution for this problem was to implement dirty region logging, which is also referred to as journaling, although that term is not used consistently and is occasionally applied to other forms of transaction logging as well. Meta-data updates are still written synchronously, but only into a small region of the disk. Later on they will be moved to their proper location. Because the logging area is a small, contiguous region on the disk, there are no long distances for the disk heads to move, even during heavy operations, so these operations are quicker than synchronous updates. Additionally the complexity of the implementation is fairly limited, so the risk of bugs being present is low. A disadvantage is that all meta-data are written twice (once into the logging region and once to the proper location) so for normal work, a performance "pessimization" might result. On the other hand, in case of a crash, all pending meta-data operations can be quickly either rolled-back or completed from the logging area after the system comes up again, resulting in a fast filesystem startup.

Kirk McKusick, the developer of Berkeley FFS, solved this problem with Soft Updates: all pending meta-data updates are kept in memory and written out to disk in a sorted sequence ("ordered meta-data updates"). This has the effect that, in case of heavy meta-data operations, later updates to an item "catch" the earlier ones if the earlier ones are still in memory and have not already been written to disk. So all operations on, say, a directory are generally performed in memory before the update is written to disk (the data blocks are sorted according to their position so that they will not be on the disk ahead of their meta-data). If the system crashes, this causes an implicit "log rewind": all operations which did not find their way to the disk appear as if they had never happened. A consistent filesystem state is maintained that appears to be the one of 30 to 60 seconds earlier. The algorithm used guarantees that all resources in use are marked as such in their appropriate bitmaps: blocks and inodes. After a crash, the only resource allocation error that occurs is that resources are marked as "used" which are actually "free". fsck(8) recognizes this situation, and frees the resources that are no longer used. It is safe to ignore the dirty state of the filesystem after a crash by forcibly mounting it with mount -f. In order to free resources that may be unused, fsck(8) needs to be run at a later time. This is the idea behind the background fsck: at system startup time, only a snapshot of the filesystem is recorded. The fsck can be run later on. All file systems can then be mounted "dirty", so the system startup proceeds in multiuser mode. Then, background fscks will be scheduled for all file systems where this is required, to free resources that may be unused. (File systems that do not use Soft Updates still need the usual foreground fsck though.)

The advantage is that meta-data operations are nearly as fast as asynchronous updates (i.e. faster than with logging, which has to write the meta-data twice). The disadvantages are the complexity of the code (implying a higher risk for bugs in an area that is highly sensitive regarding loss of user data), and a higher memory consumption. Additionally there are some idiosyncrasies one has to get used to. After a crash, the state of the filesystem appears to be somewhat "older". In situations where the standard synchronous approach would have caused some zero-length files to remain after the fsck, these files do not exist at all with a Soft Updates filesystem because neither the meta-data nor the file contents have ever been written to disk. Disk space is not released until the updates have been written to disk, which may take place some time after running rm. This may cause problems when installing large amounts of data on a filesystem that does not have enough free space to hold all the files twice.

kern.maxfiles can be raised or lowered based upon your system requirements. This variable indicates the maximum number of file descriptors on your system. When the file descriptor table is full, file: table is full will show up repeatedly in the system message buffer, which can be viewed with the dmesg command.

Each open file, socket, or fifo uses one file descriptor. A large-scale production server may easily require many thousands of file descriptors, depending on the kind and number of services running concurrently.

In older FreeBSD releases, the default value of kern.maxfiles is derived from the maxusers option in your kernel configuration file. kern.maxfiles grows proportionally to the value of maxusers. When compiling a custom kernel, it is a good idea to set this kernel configuration option according to the uses of your system. From this number, the kernel is given most of its pre-defined limits. Even though a production machine may not actually have 256 users connected at once, the resources needed may be similar to a high-scale web server.

As of FreeBSD 4.5, kern.maxusers is automatically sized at boot based on the amount of memory available in the system, and may be determined at run-time by inspecting the value of the read-only kern.maxusers sysctl. Some sites will require larger or smaller values of kern.maxusers and may set it as a loader tunable; values of 64, 128, and 256 are not uncommon. We do not recommend going above 256 unless you need a huge number of file descriptors; many of the tunable values set to their defaults by kern.maxusers may be individually overridden at boot-time or run-time in /boot/loader.conf (see the loader.conf(5) man page or the /boot/defaults/loader.conf file for some hints) or as described elsewhere in this document. Systems older than FreeBSD 4.4 must set this value via the kernel config(8) option maxusers instead.

In older releases, the system will auto-tune maxusers for you if you explicitly set it to 0. When setting this option, you will want to set maxusers to at least 4, especially if you are using the X Window System or compiling software. The reason is that the most important table set by maxusers is the maximum number of processes, which is set to 20 + 16 * maxusers, so if you set maxusers to 1, then you can only have 36 simultaneous processes, including the 18 or so that the system starts up at boot time and the 15 or so you will probably create when you start the X Window System. Even a simple task like reading a manual page will start up nine processes to filter, decompress, and view it. Setting maxusers to 64 will allow you to have up to 1044 simultaneous processes, which should be enough for nearly all uses. If, however, you see the dreaded error when trying to start another program, or are running a server with a large number of simultaneous users (like ftp.FreeBSD.org), you can always increase the number and rebuild.

The kern.ipc.somaxconn sysctl variable limits the size of the listen queue for accepting new TCP connections. The default value of 128 is typically too low for robust handling of new connections in a heavily loaded web server environment. For such environments, it is recommended to increase this value to 1024 or higher. The service daemon may itself limit the listen queue size (e.g. sendmail(8), or Apache) but will often have a directive in its configuration file to adjust the queue size. Large listen queues also do a better job of avoiding Denial of Service () attacks.

The net.inet.ip.portrange.* sysctl variables control the port number ranges automatically bound to TCP and UDP sockets. There are three ranges: a low range, a default range, and a high range. Most network programs use the default range which is controlled by the net.inet.ip.portrange.first and net.inet.ip.portrange.last, which default to 1024 and 5000, respectively. Bound port ranges are used for outgoing connections, and it is possible to run the system out of ports under certain circumstances. This most commonly occurs when you are running a heavily loaded web proxy. The port range is not an issue when running servers which handle mainly incoming connections, such as a normal web server, or has a limited number of outgoing connections, such as a mail relay. For situations where you may run yourself out of ports, it is recommended to increase net.inet.ip.portrange.last modestly. A value of 10000, 20000 or 30000 may be reasonable. You should also consider firewall effects when changing the port range. Some firewalls may block large ranges of ports (usually low-numbered ports) and expect systems to use higher ranges of ports for outgoing connections - for this reason it is not recommended that net.inet.ip.portrange.first be lowered.

The TCP Bandwidth Delay Product Limiting is similar to TCP/Vegas in NetBSD. It can be enabled by setting net.inet.tcp.inflight.enable sysctl variable to 1. The system will attempt to calculate the bandwidth delay product for each connection and limit the amount of data queued to the network to just the amount required to maintain optimum throughput.

This feature is useful if you are serving data over modems, Gigabit Ethernet, or even high speed WAN links (or any other link with a high bandwidth delay product), especially if you are also using window scaling or have configured a large send window. If you enable this option, you should also be sure to set net.inet.tcp.inflight.debug to 0 (disable debugging), and for production use setting net.inet.tcp.inflight.min to at least 6144 may be beneficial. However, note that setting high minimums may effectively disable bandwidth limiting depending on the link. The limiting feature reduces the amount of data built up in intermediate route and switch packet queues as well as reduces the amount of data built up in the local host’s interface queue. With fewer packets queued up, interactive connections, especially over slow modems, will also be able to operate with lower Round Trip Times. However, note that this feature only effects data transmission (uploading / server side). It has no effect on data reception (downloading).

Adjusting net.inet.tcp.inflight.stab is not recommended. This parameter defaults to 20, representing 2 maximal packets added to the bandwidth delay product window calculation. The additional window is required to stabilize the algorithm and improve responsiveness to changing conditions, but it can also result in higher ping times over slow links (though still much lower than you would get without the inflight algorithm). In such cases, you may wish to try reducing this parameter to 15, 10, or 5; and may also have to reduce net.inet.tcp.inflight.min (for example, to 3500) to get the desired effect. Reducing these parameters should be done as a last resort only.

A vnode is the internal representation of a file or directory. So increasing the number of vnodes available to the operating system cuts down on disk I/O. Normally this is handled by the operating system and does not need to be changed. In some cases where disk I/O is a bottleneck and the system is running out of vnodes, this setting will need to be increased. The amount of inactive and free RAM will need to be taken into account.

To see the current number of vnodes in use:

To see the maximum vnodes:

If the current vnode usage is near the maximum, increasing kern.maxvnodes by a value of 1,000 is probably a good idea. Keep an eye on the number of vfs.numvnodes. If it climbs up to the maximum again, kern.maxvnodes will need to be increased further. A shift in your memory usage as reported by top(1) should be visible. More memory should be active.

In some cases, resuming from a suspend operation will cause the mouse to fail. A known work around is to add hint.psm.0.flags="0x3000" to the /boot/loader.conf file. If this does not work then please consider sending a bug report as described above.

ACPI has three suspend to RAM (STR) states, S1-S3, and one suspend to disk state (STD), called S4. S5 is "soft off" and is the normal state your system is in when plugged in but not powered up. S4 can actually be implemented two separate ways. S4BIOS is a BIOS-assisted suspend to disk. S4OS is implemented entirely by the operating system.

Start by checking sysctl hw.acpi for the suspend-related items. Here are the results for a Thinkpad:

This means that we can use acpiconf -s to test S3, S4OS, and S5. If s4bios was one (1), we would have S4BIOS support instead of S4OS.

When testing suspend/resume, start with S1, if supported. This state is most likely to work since it does not require much driver support. No one has implemented S2 but if you have it, it is similar to S1. The next thing to try is S3. This is the deepest STR state and requires a lot of driver support to properly reinitialize your hardware. If you have problems resuming, feel free to email the ηλεκτρονική λίστα για ACPI του FreeBSD list but do not expect the problem to be resolved since there are a lot of drivers/hardware that need more testing and work.

To help isolate the problem, remove as many drivers from your kernel as possible. If it works, you can narrow down which driver is the problem by loading drivers until it fails again. Typically binary drivers like nvidia.ko, X11 display drivers, and USB will have the most problems while Ethernet interfaces usually work fine. If you can properly load/unload the drivers, you can automate this by putting the appropriate commands in /etc/rc.suspend and /etc/rc.resume. There is a commented-out example for unloading and loading a driver. Try setting hw.acpi.reset_video to zero (0) if your display is messed up after resume. Try setting longer or shorter values for hw.acpi.sleep_delay to see if that helps.

Another thing to try is load a recent Linux distribution with ACPI support and test their suspend/resume support on the same hardware. If it works on Linux, it is likely a FreeBSD driver problem and narrowing down which driver causes the problems will help us fix the problem. Note that the ACPI maintainers do not usually maintain other drivers (e.g sound, ATA, etc.) so any work done on tracking down a driver problem should probably eventually be posted to the ηλεκτρονική λίστα της έκδοσης FreeBSD-CURRENT list and mailed to the driver maintainer. If you are feeling adventurous, go ahead and start putting some debugging printf(3)s in a problematic driver to track down where in its resume function it hangs.

Finally, try disabling ACPI and enabling APM instead. If suspend/resume works with APM, you may be better off sticking with APM, especially on older hardware (pre-2000). It took vendors a while to get ACPI support correct and older hardware is more likely to have BIOS problems with ACPI.

Most system hangs are a result of lost interrupts or an interrupt storm. Chipsets have a lot of problems based on how the BIOS configures interrupts before boot, correctness of the APIC (MADT) table, and routing of the System Control Interrupt (SCI).

Interrupt storms can be distinguished from lost interrupts by checking the output of vmstat -i and looking at the line that has acpi0. If the counter is increasing at more than a couple per second, you have an interrupt storm. If the system appears hung, try breaking to DDB (CTRL+ALT+ESC on console) and type show interrupts.

Your best hope when dealing with interrupt problems is to try disabling APIC support with hint.apic.0.disabled="1" in loader.conf.

Panics are relatively rare for ACPI and are the top priority to be fixed. The first step is to isolate the steps to reproduce the panic (if possible) and get a backtrace. Follow the advice for enabling options DDB and setting up a serial console (see Είσοδος στον DDB Debugger Μέσω της Σειριακής Γραμμής) or setting up a dump(8) partition. You can get a backtrace in DDB with tr. If you have to handwrite the backtrace, be sure to at least get the lowest five (5) and top five (5) lines in the trace.

Then, try to isolate the problem by booting with ACPI disabled. If that works, you can isolate the ACPI subsystem by using various values of debug.acpi.disable. See the acpi(4) manual page for some examples.

First, try setting hw.acpi.disable_on_poweroff="0" in loader.conf(5). This keeps ACPI from disabling various events during the shutdown process. Some systems need this value set to 1 (the default) for the same reason. This usually fixes the problem of a system powering up spontaneously after a suspend or poweroff.

If you have other problems with ACPI (working with a docking station, devices not detected, etc.), please email a description to the mailing list as well; however, some of these issues may be related to unfinished parts of the ACPI subsystem so they might take a while to be implemented. Please be patient and prepared to test patches we may send you.

Some AML assumes the world consists of various Windows® versions. You can tell FreeBSD to claim it is any OS to see if this fixes problems you may have. An easy way to override this is to set hw.acpi.osname="Windows 2001" in /boot/loader.conf or other similar strings you find in the ASL.

Some methods do not explicitly return a value as the standard requires. While ACPI-CA does not handle this, FreeBSD has a workaround that allows it to return the value implicitly. You can also add explicit Return statements where required if you know what value should be returned. To force iasl to compile the ASL, use the -f flag.

After you customize your.asl, you will want to compile it, run:

You can add the -f flag to force creation of the AML, even if there are errors during compilation. Remember that some errors (e.g., missing Return statements) are automatically worked around by the interpreter.

DSDT.aml is the default output filename for iasl. You can load this instead of your BIOS’s buggy copy (which is still present in flash memory) by editing /boot/loader.conf as follows:

Be sure to copy your DSDT.aml to the /boot directory.