0. Inhaltsverzeichnis
1. Zugriff auf IDE-Geräte optimieren
2. Software-RAID-0 (Striping) mit swap-Partitionen
3. Mit Atapi-Brennern CD's brennen
4. Temporäre Dateien wirklich temporär handhaben
5. "uncached RAM" nutzen, ohne das System auszubremsen
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.
Um nun den Zugriff auf IDE-Geräte zu optimieren muss im Regelfall zunächst ein neuer Kernel mit den folgenden Optionen kompiliert werden:
CONFIG_BLK_DEV_IDEPCI=y | | (Generic PCI IDE chipset support) |
CONFIG_BLK_DEV_IDEDMA=y | | (Generic PCI bus-master DMA support) |
CONFIG_IDEDMA_AUTO=y | | (Use DMA by default when available) |
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".
zurück zum Inhaltsverzeichnis
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
Die Einträge werden einer nach dem anderen geändert, immer in der Reihenfolge "swapoff /dev/hdx", Eintrag ändern,
fstab speichern, "swapon /dev/hdx".
zurück zum Inhaltsverzeichnis
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 | | (Include IDE/Atapi CDROM support) |
CONFIG_BLK_DEV_IDESCSI=y | | (SCSI emulation support) |
CONFIG_SCSI=y | | (SCSI support) |
CONFIG_BLK_DEV_SR=y | | (SCSI CD-ROM support) |
CONFIG_SR_EXTRA_DEVS=0 | | (Maximum number of CDROM devices that can be loaded as modules) |
CONFIG_CHR_DEV_SG=y | | (SCSI generic support) |
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
Dies ist übrigens einer der ganz wenigen Anlässe, Linux neu zu
starten! Das CD-ROM-Laufwerk wird jetzt mit /dev/sr0 und der Brenner mit /dev/sr1 angesprochen. Zum Brennen selbst hat sich cdrecord
bewährt (zum Gebrauch siehe "man cdrecord").
Diese IDE-SCSI-Emulation zum CD-Brennen ist übrigens keine linuxspezifische Notwendigkeit. Auch "das wahrscheinlich längste
Virus der Welt" erkennt Atapi-Brenner nur als CD-ROM-Laufwerke. Die IDE-SCSI-Emulation wird hier vom Brennprogramm durchgeführt.
Da tauchen unter dem Menüpunkt Recorder-Info (oder ähnlich) plötzlich Begriffe aus der SCSI-Welt auf.
Wird ein Kernel 2.6.x verwendet, so ist die IDE-SCSI-Emulation nicht mehr notwendig und meist auch nicht mehr sinnvoll, da daraus Probleme resultieren können.
zurück zum Inhaltsverzeichnis
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 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!
zurück zum Inhaltsverzeichnis
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:
CONFIG_MTD=y | | (Memory Technology Device (MTD) support) |
CONFIG_MTD_BLOCK=y | | (Caching block device access to MTD devices) |
CONFIG_MTD_SLRAM=y | | (Uncached system RAM) |
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.
zurück zum Inhaltsverzeichnis
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.
|