Seit nun über 2 Jahren nutze ich einen HTPC, anfangs mit Ubuntu und Gnome Oberfläche, inzwischen mit Arch Linux und lediglich dem X Server und XBMC. Seit einigen Monaten stehe ich vor einem großen Problem, welches für mich anscheinend ziemliches Neuland ist. Bei dringenden Problemen frage ich normalerweise in Foren nach, aber dieses Mal möchte ich es selbst lösen und dazu lernen.

In meinem Beitrag über meinen HTPC habe ich bereits grob einiges zur Konfiguration gesagt, wichtig jedenfalls ist nur, dass ich zwei 500 GB Western Digital “Caviar Black” Festplatten in einem Software RAID1 mittels mdadm laufen habe. Eigentlich sind diese Festplatten ja für ihre relativ gute Performance bekannt, aber inzwischen stehe ich vor einem gewaltigen Problem. Aufgefallen ist es mir, als das Fernsehen extrem geruckelt hat und teilweise gar nicht mehr funktioniert hat. XBMC sagte etwas von “Zwischenpuffern” und Tvheadend spuckte haufenweise Meldungen wie MPEG2VIDEO #512: Continuity counter error, 2 duplicate log lines suppressed aus.

Anfangs habe ich die TV-Karte verdächtigt, aber auch die anderen beiden haben keine besseren Ergebnisse erzielt. Das seltsamste an der Sache ist allerdings, dass das Problem rein zufällig aufzutreten scheint. Irgendwann ist mir aufgefallen, dass die Lese- und Schreibgeschwindigkeiten der Festplatten sich nur noch im Bereich von 2-4 MB/s bewegt haben. Zuerst dachte ich an zwei unabhängige Probleme, aber schnell hat sich herausgestellt, dass beides zusammenhängt.

Eine Zeit lang war ich auf dem Irrweg, da das Problem zufälligerweise nur auftrat, wenn ich im BIOS den SATA Modus nicht auf IDE, sondern auf AHCI gestellt habe. Inzwischen tritt das Problem aber bei beiden Einstellungen auf.

In einigen Foren habe ich gelesen, dass defekte Blöcke auf RAID Festplatten zu solchen Problemen führen können. Die S.M.A.R.T Werte der beiden Festplatten sehen aber sehr gut aus, gelegentlich werde ich es sicherheitshalber mit badblocks überprüfen. Die anderen 3 Festplatten, die nicht im RAID Verbund sind, habe ich, um Fehlerquellen auszuschließen, ausgebaut. Diese überprüfe ich gerade und formatiere sie bei der gelegenheit in ext4 um.

iotop

Das Problem besteht jedenfalls weiterhin, zwar nicht ständig, aber manchmal. Wenn das Problem auftaucht, merke ich das sogar an der SSH Verbindung, die sehr träge und verzöhert zu sein scheint. Sehr nützlich ist dabei das Tool iotop, welches, wie der Name vermuten lässt, I/O Aktivitäten und die dazugehörigen Prozesse anzeigt. Besonders interessant ist dort die Spalte IO, welches die Schreib- und Leseaktivitäten eines Prozesses anzeigt. Dank iotop konnte ich das Problem gut eingrenzen, denn manchmal belegt der Prozess [jbd2/md3-8] die Festplatte zu 99%. Das Journaling Block Device, wenn ich es recht verstehe, kümmert sich um das Journal, also quasi das Inhaltverzeichnis des Dateisystems. Nach kurzer Suche im Internet scheinen einige Leute damit Probleme zu haben, aber das Journal zu deaktivieren, wie teilweise empfohlen, halte ich für zu riskant, da bei einem Absturz die Gefahr des Datenverlustet groß ist.

Hopple, gerade eben ist das Problem wieder aufgetreten:

top

Ebenfalls interessant ist das Tool top, welches laufende Prozesse inklusive CPU Auslastung, Arbeitsspeicherverbrauch und vieles mehr anzeigt. Meistens benutze ich htop, weshalb ich wahrscheinlich erst jetzt über das Problem gestolpert bin. Interessant ist vor allem die 3. Zeile von top:

Dort wird angezeigt, mit welchen “Aufgaben” der Prozessor beschäftigt ist (User Prozesse, System Prozesse, “genicete” Prozesse, Leerlauf und IO Wait. Dieser Wert sagt aus, wie oft der Prozessor auf die Festplatte warten muss. Bei einem nicht stark genutzem Rechner wie meinem Heimserver / HTPC sollte der Wert normalerweise zwischen 0% und 2% liegen. Wenn die Probleme auftreten liegt der Wert aber im Schnitt bei 50%.

Noch ein Hoppla, beim schreiben des Artikel ist das Problem wieder aufgetreten, deshalb hier die gleiche Zeile noch einmal zum Vergleich:

Wie gesagt, der IO Wait Wert schwankt sehr stark.

dd

Ebenfalls sehr nützlich ist das kleine Tool dd, welches ich normalerweise nutze, um Images von Datenträgern zu erstellen. Generell kann man damit alle möglichen Daten hin und her schieben, auch einen Haufen Nullen in einen Datei auf die Festplatte:

Das Problem ist, dass dd sehr unterschiedliche Werte liefert. Wenn das Problem nicht auftritt, kann ich mit 80 – 100 MB/s auf die Platte schreiben. Vor ein paar Minuten ist das Problem wieder aufgetreten und ich kann mit ca. 16 MB/s schreiben, manchmal aber auch nur mit 2 – 4 MB/s.

Möchte man die Datei lesen, schickt man sie am besten ins Nirvana, aber vorsicht ist geboten. Der Linux Kernel beherrscht ein wunderbares disk caching, weshalb bei kleinen Dateien ein deutlich zu hoher Wert heraus kommt. Möchte man genauere Werte haben, sollte man eine Datei erstellen, dessen Größe ein deutliches Vielfaches vom Arbeitsspeicher ist.

Und nun?

Es gibt noch viel mehr Programme, mit denen sich das System genauer untersuchen lässt, z.B. iostat, isag, mpstat, pidstat, sadf, sar. Diese sind bei Arch Linux alle im Paket sysstat enthalten. Ich kenne diese Programme aber noch nicht und muss ich erst noch durch ein paar Manpages kämpfen, bevor ich irgendwelche Aussagen treffen kann. Ich halte es auch für unwahrscheinlich, dass es an meinem RAID liegt, da es im Moment nicht synchronisiert, das Problem aber trotzdem besteht. Außerdem lief es eine ganze Zeit lang sehr gut. Theoretisch kommt eine defekte Festplatte in Frage, aber noch weiß ich es nicht. Generell ist es ja sehr seltsam, dass das Problem kommt und geht. Es scheint reiner Zufall zu sein, ich weiß nicht, wie ich das Problem auslösen kann.

Ich hoffe, dass ich bald neues berichten kann…

UPDATE 28.03.2012

Scheinbar habe ich die Ursache des Problems so halbwegs gefunden. Dass jbd2 als Ursache in Verdacht gekommen ist, hat mich etwas in die irre geführt. Da ich festgestellt habe, dass dieses Problem mit deaktiviertem tvheadend nicht aufgetreten ist, habe ich den Fehler dort vermutet. Tatsächlich aber war es die Option “Deaktiviere EPG Aktualisierungen während der TV Wiedergabe” in XBMC, welche nicht aktiviert war.

Ich hoffe, dass nun weiterhin alles flüssig läuft, aber ich bin guter Dinge. Endlich laufen nun auch 2 TV Karten parallel problemlos, so dass ich endlich Bob Ross aufnehmen kann, ohne dass sich die Karten in die Quere kommen.