1. Zugriff auf IDE-Geräte optimieren

"man hdparm" sagt zwar eigentlich alles zu diesem Thema. Leider ist diese Manpage gerade im Bezug auf DMA nicht besonders aktuell. Die nachfolgenden Ausführungen gelten für die folgenden Voraussetzungen:

• Es ist ein Sockel-7-Mainboard oder ein moderneres Mainboard vorhanden. 
• Der Onboard-IDE-Controller und, sofern vorhanden, auch der Offboard-IDE-Controller werden von Linux unterstützt. 
• Es sind IDE-Geräte angeschlossen, die sich mit dem Controller vertragen. Hier gibt es bei Festplatten in Ausnahmefällen Probleme. 
• Atapi-Geräte sollten immer an den Onboard-Controller angeschlossen werden, da der Anschluss am Offboard-Controller häufig Probleme verursacht.

CONFIG_BLK_DEV_IDEPCI=y

CONFIG_BLK_DEV_IDEDMA=y

CONFIG_IDEDMA_AUTO=y

Außerdem muss die Unterstützung für den/die Onboard-IDE-Controller und, sofern vorhanden, auch für den/die Offboard-IDE-Controller fest in den Kernel hineinkompiliert werden. Sockel-7-Mainboards haben normalerweise keinen RZ1000- oder CMD640-IDE-Controller, weshalb diese Dinge ganz aus dem Kernel raus können.
Nach dem erfolgreichen Start mit dem neuen Kernel kommt nun hdparm zum Zuge.
Zunächst wird für alle Festplatten der Befehl "hdparm -i /dev/hdx" (x = Devicename der IDE-Festplatte) ausgeführt. Die Antwort enthält vor allem eine wichtige Angabe, nämlich MaxMultSect=*, wobei * eine Zahl (Vielfaches von 2) ist. Dann wird einmal manuell für alle IDE-Geräte hdparm aktiviert. Für Festplatten ist "hdparm -c1d1m*u1W1 /dev/hdx" (* = MaxMultSect; x = Devicename der IDE-Festplatte) die richtige Wahl. -d1 ist zwar meistens redundant, aber es stört auch nicht. Möchte man auf einem Arbeitsplatzrechner außerdem die Festplatten nach einer bestimmten Zeit herunterfahren, kommt noch die Option -S??? (? = Ziffer) hinzu.
Atapi-Geräte akzeptieren ohne einliegenden Datenträger oft nur "hdparm -c1u1 /dev/hdx" (x = Devicename des Atapi-Gerätes). Alles andere führt hier meist zu Fehlermeldungen. Bei relativ neuen ATAPI-Geräten, die an relativ neue IDE-Controller angeschlossen sind, kann ein "hdparm -c1d1u1 /dev/hdx" (x = Devicename des Atapi-Gerätes) funktionieren. Dies sollte dann aber mit einem größeren Datentransfer vom ATAPI-Gerät zur Festplatte überprüft werden. Wichtig! Der obige Befehl wird auch dann für CD-Geräte (insbesondere Brenner) genau so verwendet, wenn für diese Geräte IDE-SCSI-Emulation aktiv ist. Die Eingabe "hdparm -i /dev/scd0" führt bereits zu einer Fehlermeldung. Jetzt werden alle IDE-Geräte mit größeren Datentransferaktionen (das sollten schon jeweils ein paar hundert Megabytes sein) gequält. Kommt es dabei zu keinen Fehlermeldungen (auch nicht in /var/log/messages und /var/log/warn), können die hdparm-Befehle in die Datei rc.local (liegt in /etc/rc.d) oder boot.local (liegt in /sbin/init.d oder /etc/init.d) übernommen werden, damit der optimierte Zugriff auf die IDE-Geräte gleich bei jedem Start aktiviert wird.

Bei sehr alten PCI-Mainboards (Sockel-4 oder 5), VLB- und ISA-Mainboards lassen sich meist nicht alle der oben genannten hdparm-Optionen aktivieren. Hier ist große Vorsicht geboten und es sollte, wenn überhaupt, hdparm nur mit den Optionen gestartet werden, die wirklich keine Probleme verursachen! Sonst droht Datenverlust bis hin zum Systemcrash! Außerdem muss, notfalls durch Aufschrauben des Rechners, geklärt werden, ob nur PCI- oder VLB-IDE-Controller vorhanden sind oder ob auch ISA-IDE-Controller eingebaut sind und benutzt werden. Bei alten PCI-Mainboards ist mitunter der zweite IDE-Controller ein ISA-IDE-Controller. Bei VLB-Mainboards befinden sich die IDE-Controller normalerweise nicht auf dem Mainboard, sondern werden über VLB- oder ISA-Steckkarten bereit gestellt. Dort können zwei VLB-IDE-Controller (meist gemeinsam auf einer VLB-Steckkarte), ein VLB-IDE-Controller und ggf. ein ISA-Controller (auf einer VLB- und ggf. einer ISA-Steckkarte) oder auch nur ein oder zwei ISA-IDE-Controller vorhanden sein. Für PCI- oder VLB-IDE-Controller kann man "hdparm -c1m*u1W1 /dev/hdx" veruschen, für ISA-IDE-Controller "hdparm -m*u1W1 /dev/hdx".

2. Software-RAID-0 (Striping) mit swap-Partitionen

Die Hardwarevoraussetzungen im Zusammenhang mit IDE-Festplatten dafür sind bereits auf der Hardwareseite erwähnt. SCSI-Systeme, die bereits unter Linux laufen, bedürfen keiner weiteren Vorbereitung. Das weitere Vorgehen ist für swap-Partitionen ganz einfach und wegen der großen Beanspruchung dieser Partitionen auch besonders lohnenswert. Außerdem sind keinerlei Tools erforderlich, um swap-Partitionen mit Striping zu betreiben. Die einzelnen swap-Partitionen sollten allerdings gleich groß sein. Ist dies nicht der Fall, z.B. wegen unterschiedlicher Plattengeometrien, greift das Striping nur für Größe der kleinsten Partition multipliziert mit der Anzahl der Partitionen.
Nachfolgend wird als Beispiel ein PC mit vier IDE-Festplatten (für SCSI-Festplatten gilt aber das Gleiche), hda und hdc am Onboardcontroller, hde und hdg am Offboardcontroller und vier gleich großen swap-Partitionen auf /dev/hda2, /dev/hdc2, /dev/hde1 und /dev/hdg1 angenommen. Standardmäßig haben alle swap-Partitionen unterschiedliche Prioritäten, so dass die Partitionen nacheinander belegt werden, also die Partition mit der höchsten Priorität auch die höchste Last hat (siehe auch "man 2 swapon"). Damit die Last auf alle Partitionen gleichmäßig verteilt wird, ist lediglich eine Änderung in der Datei /etc/fstab erforderlich:

# fstab
[...]
/dev/hda2    swap    swap    pri=1    0  0
/dev/hdc2    swap    swap    pri=1    0  0
/dev/hde1    swap    swap    pri=1    0  0
/dev/hdg1    swap    swap    pri=1    0  0
[...]
# End of fstab

3. Mit Atapi-Brennern CD's brennen

Dieser Tipp gilt nicht mehr in Verbindung mit einem Kernel 2.6.x!
Nachfolgend wird von einem PC ohne SCSI-Komponenten ausgegangen. /dev/hda und /dev/hdc sind Festplatten, /dev/hdb ist ein CD-ROM- (oder DVD-ROM-) Laufwerk, /dev/hdd ist der Atapi-Brenner. Es ist Linux mit Kernel 2.2.14 oder höher und installiert; gestartet wird mit lilo.
Der Atapi-Brenner wird standardmäßig nur als normales CD-ROM-Laufwerk erkannt. Um CD's brennen zu können, muss für dieses Gerät eine IDE-SCSI-Emulation durchgeführt werden. Im Regelfall muss dazu ein neuer Kernel mit den folgenden Optionen kompiliert werden:

CONFIG_BLK_DEV_IDECD=n

CONFIG_BLK_DEV_IDESCSI=y

CONFIG_SCSI=y

CONFIG_BLK_DEV_SR=y

CONFIG_SR_EXTRA_DEVS=0

CONFIG_CHR_DEV_SG=y

Mehr SCSI-Kram wird hier nicht gebraucht! Es ist extrem wichtig, dass "Include IDE/Atapi CDROM support" ganz aus dem Kernel raus fliegt, also auch nicht als Modul existiert!!! Es empfiehlt sich auch nicht, den SCSI-Kram als Module zu kompilieren. Die IDE-SCSI-Emulation wirkt in dieser Form auf alle Atapi-CD-Geräte. Mit diversen Verrenkungen lässt sich diese Emulation zwar auf den Brenner beschränken, aber konsequent ist es (und es erspart manches Durcheinander), die Emulation gleich ab Start für alle Atapi-CD-Geräte zu aktivieren, zumal es gut funktioniert. Um dies zu erreichen muss der Kernel mit dem folgenden Bootparameter gebootet werden:

hdb=ide-scsi hdd=ide-scsi

4. Temporäre Dateien wirklich temporär handhaben

Linuxprogramme legen temporäre Dateien normalerweise in /tmp ab. Dieses Verzeichnis liegt auf irgend einer Festplatte. Viele Programme (vor allem unter X) versäumen es aber, nach deren Beendigung ihren temporären "Müll" wieder zu beseitigen, so dass die Partition, die /tmp enthält, langsam vollgemüllt wird. Da temporäre Dateien nach dem Ende des verursachenden Programms nicht mehr gebraucht werden, haben sie auf einer Festplatte nichts zu suchen. Seit Kernel 2.4.4 gibt es nun das tmpfs, ein Dateisystem, dass in einer dynamischen, also je nach Bedarf wachsenden und schrumpfenden RAM-Disk residiert. Bei Bedarf kann diese Art RAM-Disk sogar ausgelagert werden. Wird die RAM-Disk mit den temporären Dateien ausgelagert, liegen diese zwar auch wieder auf einer Festplatte, aber sie verschwinden von dort auch wieder. Spätestens nach einem Shutdown ist der Müll weg.

Um nun temporäre Dateien von der Festplatte zu verbannen, sind folgende Schritte erforderlich:

• Es werden die Sourcen des Kernels 2.4.4 (oder höher) installiert. 
• Es wird ein neuer Kernel kompiliert, der folgendes als festen Bestandteil enthält:
  Virtual memory file system support:

  CONFIG_TMPFS=y

   
• Der neue Kernel wird gebootet. 
• In der Datei /etc/fstab wird folgender Eintrag eingefügt:
  

  tmpfs    /tmp    tmpfs    defaults,size=*m 0  0

  * = Zahl. Gibt die maximale Größe des tmpfs in Megabytes an. 
• Alle Anwendungen, die temporäre Dateien erzeugen, werden beendet. 
• Der Inhalt von /tmp wird gelöscht. 
• Es wird "mount /tmp" ausgeführt. Ab jetzt werden temporäre Dateien wirklich temporär gehandhabt.

Es gibt keine allgemeine Regel für die maximale Größe des tmpfs. Diese hängt von den verwendeten Programmen ab. Unter X entstehen meist mehr temporäre Dateien als an der Konsole. Die maximale Größe sollte aber nicht größer als das verfügbare RAM sein und muss kleiner als der gesamte verfügbare Speicher (RAM + swap) sein! Bei reichlich RAM (> 128 MB) kann man die Größe auch erst einmal auf size=128m begrenzen. Sollte es wirklich einmal eng werden, kann die Größe mit remount nachträglich geändert werden, wozu natürlich laufende Anwendungen erst beendet werden müssen. Um temporären Müll auf einem tmpfs los zu werden, muss nämlich keineswegs neu gebootet werden! Es genügt, alle Anwendungen, die temporäre Dateien erzeugen, zu beenden und dann mit
umount /tmp
mount /tmp
den Müll zu entsorgen.
Und wer nicht glaubt, dass das tmpfs dynamisch arbeitet, kann sich leicht mit "df" und "free -t" davon überzeugen. "df" zeigt den mit "size" vorgegebenen Maximalwert als verfügbaren Speicherplatz und den aktuellen Platzverbrauch an. "free -t" hingegen zeigt den tatsächlich freien Speicher an. Wenn also in /tmp gerade nichts liegt, belegt tmpfs auch keinen Speicher. Dies ist der enorme Vorteil gegenüber statischen RAM-Disks, die ja immer gleich Speicher entsprechend ihrer Größe belegen, egal wie viel Platz tatsächlich auf der RAM-Disk gerade belegt ist. Ganz streng genommen belegt der Kernel natürlich ein paar kB RAM, um das tmpfs bereitstellen zu können.
Diese Prozedur empfiehlt sich auch für /var/tmp, wo ebenfalls Programme temporäre Dateien ablegen. ACHTUNG! Die Summe der Maximalgrößen aller tmpfs muss kleiner als der gesamte verfügbare Speicher (RAM + swap) sein!

5. "uncached RAM" nutzen, ohne das System auszubremsen

Insbesondere Sockel-7- und Sockel-Super-7-Mainboards, aber auch diverse andere Mainboards können meist mit mehr Arbeitsspeicher (RAM) betrieben werden, als von dem dort vorhandenen L2-Cache verwaltet werden kann (cacheable RAM area). Übersteigt der installierte RAM die Größe der "cacheable RAM area", so führt dies meist zu einem Leistungsverlust des Systems, da Zugriffe auf "uncached RAM" erheblich langsamer sind als Zugriffe auf "cached RAM". Allerdings sei hier erwähnt, dass Zugriffe auf "uncached RAM" immer noch erheblich schneller sind als Zugriffe auf die Festplatte. Wenn also häufig mit vielen oder großen Dateien oder Programmen, die generell nicht auslagern, gearbeitet wird, ist mehr RAM immer noch besser als Auslagerung auf die Festplatte oder einfach weniger verfügbarer RAM. Typische Fälle dafür sind z.B. der Einsatz des PCs als Fileserver oder der Gebrauch des gcc (GNU-C-Compiler). Besonders häufig trifft man "uncached RAM" in zwei Situationen an. Die meisten Sockel-7-Mainboards können 4 × 32MB EDO-RAM = 128 MB RAM aufnehmen, die "cacheable RAM area" ist jedoch nur 64 MB groß. Da EDO-RAM mit seiner Zugriffszeit von minimal 60 ns im Vergleich zum mit maximal 66 MHz getakteten Frondsidebus sehr langsam ist, macht sich in solchen Systemen "uncached RAM" besonders unangenehm bemerkbar. Die Sockel-Super-7-Mainboards können oft 2 × 128MB SD-RAM = 256 MB RAM bei zwei Steckplätzen für RAM-Module oder 3 × 128MB SD-RAM = 384 MB RAM bei drei Steckplätzen für RAM-Module aufnehmen, die "cacheable RAM area" ist oft jedoch nur 128 MB groß. Durch "uncached RAM" werden solche Systeme allerdings weniger stark ausgebremst, da SD-RAM erheblich kürzere Zugriffszeiten als EDO-RAM aufweist. SD-RAM-Module gibt es mit Zugriffszeiten von 10 ns, 8 ns und 7 ns, was den Bezeichnungen PC-66, PC-100 und PC-133 entspricht. Der Frontsidebus ist mit maximal 100 MHz getaktet, wobei dann sinnvollerweise PC-100-Module verwendet werden, auch wenn einige Mainboards in diesem Fall PC-66-Module verwenden könnten. Meist können auch PC-133-Module verwendet werden. Ist der Frontsidebus mit maximal 66 MHz getaktet, können PC-66 oder meist auch PC-100-Module verwendet werden. PC-133-Module verursachen hier unter Umständen Probleme.

Nachfoldend wird von einem Sockel-Super-7-Mainboard mit einer "cacheable RAM area" von 128 MB ausgegangen, dass mit 384 MB SD-RAM PC-100 bestückt ist. Es läuft Kernel 2.4.26. Unter Linux könnte man sich des "uncached RAM" ganz einfach entledigen, in dem man den Kernel mit dem Bootparameter "mem=128M" bootet. Damit verschenkt man aber 256 MB RAM! Da aber Zugriffe auf diesen "uncached RAM" immer noch erheblich schneller sind als Zugriffe auf die Festplatte, bietet sich dieser Speicherbereich als idealer Platz für eine extrem schnelle swap-Partition an. Dazu muss allerdings ein neuer Kernel mit den folgenden Optionen kompiliert werden:

Bevor dieser neue Kernel gebootet wird, müssen noch zwei Befehle ausgeführt werden: 
mknod /dev/mtd0 c 90 0 
mknod /dev/mtdblock0 b 31 0 
In der /etc/fstab müssen die vorhandenen swap-Partitionen auf eine Priorität von 2 (pri=2) oder größer (größerer Zahlenwert = niedrigere Priorität) gesetzt werden. Jetzt wird der neue Kernel mit dem Bootparameter

mem=128M slram=ramswap,128M,+256M

gebootet. Nach erfogreichem Boot wird in einer vorhandenen /var/log/boot.msg oder mit "dmesg > file" kontrolliert, ob slram geladen wurde. Außerdem muss dort die Meldung "128MB LOWMEM available." auftauchen. Zuvor waren es ja 384 MB. Im Erfolgsfall müssen nun noch zwei Befehle ausgeführt werden: 
mkswap /dev/mtdblock0 
swapon -p1 /dev/mtdblock0 
"free -t" zeigt nun 256 MB mehr swapspace an. Um diesen swapspace zukünftig bei jedem Systemstart zu aktivieren, werden die beiden Befehle 
/sbin/mkswap /dev/mtdblock0 
/sbin/swapon -p1 /dev/mtdblock0 
in die Datei rc.local (liegt in /etc/rc.d) oder boot.local (liegt in /sbin/init.d oder /etc/init.d) übernommen.

Der hier verwendete Bootparameter ist wie folgt aufgebaut: 
mem=<Größe der "cacheable RAM area" in MB>M 
slram=<beliebiger Name>,<Größe der "cacheable RAM area" in MB>M,+<Größe des restlichen vorhandenen RAM in MB>M 
Da der L2-Cache immer den untersten Bereich des vorhandenen Speichers verwaltet, in diesem Beispiel also den Bereich von 0...128 MB, stellt "mem=128M" sicher, dass Linux nur "cached RAM" als Arbeitsspeicher verwendet. Da die im "uncached RAM" liegende swap-Partition mit der Priorität 1 eingebunden ist, wird zunächst nur in den "uncached RAM" ausgelagert. Erst wenn diese swap-Partition voll ist, wird auf die Festplatte(n) ausgelagert.

32-Bit-Prozessoren können maximal 4 GB RAM verwalten und jedes moderne Mainboard, genauer gesagt der L2-Cache, sollte das auch können. Auch mit dem hier beschriebenen Verfahren kann man ein 32-Bit-System nicht mit mehr als 4 GB RAM betreiben.

Ich übernehme keinerlei Gewähr für die auf dieser Seite gegebenen Tipps. Die Anwendung geschieht vollständig auf eigene Gefahr. Jegliche Haftung meinerseits ist daher ausgeschlossen.