Festplattenleistung mittels hdparm optimieren und Fehler korrigieren

Nach langer Testphase, bei der ich so gut wie alle für mich in Frage kommenden Programme und Tools installiert und viele Konfigurationsmöglichkeiten getestet hatte, setzte ich mein Linux-Gentoo-System neu auf, um mit meinen Erfahrungen und neu erlangten Kenntnissen ein "sauberes" System auf die Beine zu stellen. Doch bei der Installation von Gentoo (für den, der mit dem Begriff Gentoo nichts anfangen kann: dies ist eine weitere Linux-Distribution) ist mir ein kleiner Fehler mit großer Wirkung eingeschlichen, der sich vor allem auf die Festplattenleistung ausgewirkt hat.

In dieser Anleitung soll systematisch gezeigt werden, wie das Problem mit der Festplattenleistung erkannt bzw. gelöst wurde und wofür man das Tool hdparm benutzt.

Problem: Bei Festplattenzugriff bricht Leistung ein

Das Problem trat unmittelbar nach der Installation des Windows Managers KDE auf: nachdem KDE gestartet und die Programme geladen wurden, brach die Systemleistung für einige Sekunden dramatisch ein. Dies äußerte sich darin, dass sich die Maus nicht mehr bewegen ließ und diese erst wenige Sekunden später reagierte. Dieses Phänomen tritt beispielsweise auch auf, wenn man bei einem Video-Rendering-Programm die Priorität auf maximal setzt, so dass dieses beim Berechnen vollen Zugriff auf die Systemressourcen hat. Auch hier ist es unmöglich, den Rechner noch zu bedienen, da das Programm die gesamten Ressourcen für sich in Anspruch nimmt.

Das gleiche Problem trat ebenfalls auf, wenn man größere Dateien kopiert hatte oder wenn beim Kompilieren von Programme die Binaries in die Verzeichnise gespeichert wurden. Das komplette System war für kurze Zeit nicht ansprechbar und ein Arbeiten war unmöglich. Aufgrund des Vergleiches mit dem Video-Rendering-Programms wusste ich, dass aus irgendeinem Grund die Systemleistung unheimlich stark einbricht, wenn größere Zugriffe auf die Festplatte erfolgen.

Schrittweise Vorgehensweise

Der erste Gedanke, den ich hatte, war ein eventueller Defekt der Festplatte. Doch dies konnte ich auch schnell wieder ausschließen, denn ich hatte zwei eingebaute Festplatten und eine externe USB-Festplatte in dem System. Bei jedem der drei Festplatten trat dieses merkwürdige Phänomen auf. So kam auch ein defektes Übertragungsmedium (IDE- oder USB-Kabel) nicht nicht in Frage.

Wenn ein Hardware-Defekt nicht vorliegt, sucht man den Fehler in der Software oder bei der Treiberkonfiguration. Konnte der Windows Manager KDE mit diesem Problem zusammenhängen? Um diesen eher unwahrscheinlichen Fall auszuschließen, habe ich einfach einen anderen Window Manager gestartet, doch auch hier trat dieser dramatische Performance-Einbruch auf.

Demzufolge musste das Problem letztendlich beim Treiber liegen, so dass ich fälschlicherweise versucht habe, mit "cat /proc/pci" bzw. "lspci" mir anzeigen zu lassen, welche Treiber denn nun geladen wurden. Warum fälschlicherweise? Die beiden oben genannten Befehle zeigen einem zwar die im System eingebauten PCI-Komponenten an, doch heißt dies noch lange nicht, ob die Treiber auch wirklich geladen wurden. "cat /proc/pci" bzw. "lspci" sind lediglich gut dafür geeignet, um Informationen zur Hardware herauszubekommen. 

  bash-2.05b# lspci 
  0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP...
  0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge
  0000:00:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL818...
  0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1...
  0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1...
  0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1...
  0000:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
  0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
  0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/...
  0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/...
  0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-I...
  0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AP [R...
  0000:01:00.1 Display controller: ATI Technologies Inc RV350 AP [Radeon 9...

Laut dieser Anzeige sieht alles wunderbar aus, denn die Host Bridge, PCI Bridge und das IDE-Interface werden angezeigt. Aber wie gesagt, lspci zeigt einem nur die Hardware an, mehr nicht.

Nachdem ich einige mögliche Fehlerquellen ausgeschlossen hatte, habe ich mir die Daten für die Festplatte auslesen lassen. Ein hervorragendes Tool, mit dem man diese machen kann, nennt sich "hdparm". Mit hdparm kann man sich Informationen zu CD- und Festplatten-Laufwerken anzeigen lassen, die Laufwerke auf Leistung überprüfen und auch Einstellungen für diese vornehmen. 

 bash-2.05b# hdparm -iv /dev/hda

 /dev/hda:
 multcount    = 16 (on)
 IO_support   =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 65535/16/63, sectors = 81964302336, start = 0

 Model=Maxtor 6Y080P0, FwRev=YAR41BW0, SerialNo=Y345KC4E
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=7936kB, MaxMultSect=16, MultSect=16
 CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=160086528
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: (null):

 * signifies the current active mode

Mit hdparm -iv /dev/ ließt man sämtliche Informationen zu den Laufwerken aus. Und hier sieht man auch schon den Fehler: using_dma ist auf off gestellt. Dies bedeutet, dass für die Festplatte kein DMA benutzt wird. DMA steht für Direct Memory Access und ermöglicht dem System den direkten Zugriff auf die Festplatte, ohne die CPU zu beanspruchen. Da dieses in diesem Fall deaktiviert ist, bricht die Festplattenleistung stark ein und die CPU wird unnötig belastet. 

 bash-2.05b# hdparm -tT /dev/hda

 /dev/hda:
 Timing cached reads:   1296 MB in  2.00 seconds = 646.48 MB/sec
 Timing buffered disk reads:   14 MB in  3.31 seconds =   4.24 MB/sec

4,24 MB in der Sekunde Datendurchsatz sind für eine 80 GB Festplatte mit UDMA 133, 7.200 U/Min und 8 MB Cache mehr als lachhaft. Na dann, worauf warten wir noch lange? Aktivieren wir doch einfach DMA mit dem Befehl "hdparm -d 1 /dev/hda". Nachdem ich aber dieses in die Konsole eingetippt hatte, begrüßte mich eine Meldung, dass der Zugriff verweigert wurdeund die Einstellung nicht vorgenommen werden konnte!

Wenn man DMA nicht aktivieren kann, liegt in der Regel das Problem in der fehlenden Treiberunterstützung im Kernel. Daraufhin habe ich mir noch einmal meine Kernel-Konfiguration angeschaut. Und wahrhaftig, ich hatte vergessen, den Chipsatz-Treiber von meinem Mainboard in den Kernel einzukompilieren! 

 Device Drivers  ---> 
         ATA/ATAPI/MFM/RLL support  ---> 
              <*>         VIA82CXXX chipset support

Nachdem ich den Kernel neu kompiliert hatte und von diesem gebootet habe, konnte ich nun auch mit "hdparm -d 1 /dev/hda" den DMA-Modus aktivieren. 

  bash-2.05b# hdparm -d 1 /dev/hda

 /dev/hda:
 setting using_dma to 1 (on)
 using_dma    =  1 (on)

Anschließend versicherte ich mich, ob DMA nun auch wirklich aktiviert wurde: 

 bash-2.05b# hdparm -iv /dev/hda

 /dev/hda:
 multcount    = 16 (on)
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 65535/16/63, sectors = 81964302336, start = 0

Wie man sieht, steht using_dma auf on, das heißt also, DMA wurde aktiviert. Der hdparm-Benchmark müsste nun auch bessere Werte ausgeben: 

 bash-2.05b# hdparm -Tt /dev/hda

 /dev/hda:
 Timing cached reads:   1152 MB in  2.00 seconds = 575.22 MB/sec
 Timing buffered disk reads:  154 MB in  3.00 seconds =  51.31 MB/sec

Mit aktivierten DMA erreicht die Festplatte 51,31 MB in der Sekunde, das sind mehr als das 10fache als ohne DMA. Auch die Probleme mit den Performance-Einbußen sind verschwunden, so dass wir abschließend den Übeltäter festlegen können: der fehlende Chipsatztreiber und das daraus resultierende deaktivierte DMA war der Grund allen Übels.

hdparm automatisch starten

Damit wir die Einstellungen nicht bei jedem Neustart vornehmen müssen, sollte man hdparm automatisch starten lassen. Wir fügen hdparm also zum Default-Runlevel hinzu: 

 bash-2.05b# rc-update add hdparm default

Nachdem wir hdparm zum Default-Runlevel hinzugefügt haben, werden bei jedem Neustart die Einstellunge automatisch gesetzt, in unserem Fall das Aktivieren von DMA.