Category: UNIX

Mit den Systemaufrufen:

struct sched_param sp;
sched_setscheduler(pid,SCHED_RR,&sp);

lässt sich – sofern man über CAP_SYS_NICE Capabilities verfügt – jederzeit unter Linux der Prozess pid in einen soften Realtime Mode bringen. Hierbei übernimmt das Kernelmodul sched_rt das Prozessscheduling von sched_fair (Complete Fair Scheduler).

Beachtenswert hierbei ist wieder die gewöhnungsbedürftige Invertierung der RT-Prioritäten. Der Aufruf

struct sched_param sp;
sp.sched_priority = 14;

setzt die RT-Priorität auf 14 – welches im Linux Prioritätenarray dann 99-14=85 ergibt. Dies bestätigt die Ausgabe Prio des folgenden Befehls:

cat /proc/<pid>/sched

Die Capability CAP_SYS_NICE muss übrigens nicht zwangsläufig bedeuten, dass nur root den Prozess starten muss. Mittels den libcap-progs kann auch folgender Befehl dem Programm auf Filesystemebene diese Capability zugestehen.

setcap cap_sys_nice=ep /pfad/zu/meinem/programm

Erforderlich dazu ist, dass der Kernel mit CONFIG_SECURITY_FILE_CAPABILITIES=y kompiliert wurde. Die Linux Kernel welche von Novell gebaut wurden (SLES,openSUSE) müssen noch mit dem Bootparameter file_caps=1 gestartet werden, da diese die Fähigkeit zwar auch einkompiliert haben, aber standardmässig deaktiviert ist.
Der Bootparameter ist übrigens exklusiv nur auf Novell Systemen vorhanden – der offizielle Vanilla Kernel Bootparameter bzgl. Capabilities lautet no_file_caps ,um die Fähigkeit beim Start zu deaktivieren.

Ein nagelneuer Computer. 2 Western Digital WD10TPVT Festplatten im Linux Software RAID-1 Verbund.
Eine neue openSUSE 11.2 Installation.

Ein Benutzer Erlebnis irgendwo zwischen C16 (auf Datasette warten) und C64 (hätte ich doch die Speichererweiterung gekauft). Immer wieder hängt der Rechner teilweise bis zu 40s. ohne eine Reaktion zu zeigen.

Was war los?
top meldet keine nenneswerte CPU Belastung.
rote Festplatten LED leuchtet ununterbrochen…. -> wir fragen iostat
iostat meldet immer wieder 100% CPU Auslastung durch iowait – Festplatten sind an der Leistungsgrenze…
…da Firefox die Frechheit hatte kurz mal ein paar 100kB wegzusichern 😉

Wenn die Festplatten wegen so einer Kleinigkeit bereits an der Leistungsgrenze operieren, kann man es nicht durch Tuning verbessern – es muss ein grundlegendes Konfigurationsproblem sein… aber welches?!

Nach vielen Stunden stolperte ich über folgenden Artikel:
Problem with WD Advanced Format drive in LINUX (WD15EARS)

Dort wird von ähnlichen Problemen bei einer anderen WD Festplatte berichtet, welche 4kB Sektoren benutzt (die letzten 30 Jahren benutzte man durchgehend 512Byte Sektoren). Hm, benutzt denn meine Festplatte ev. auch diese 4kB Sektoren.

Laut der WD Webseite nicht, denn die 1TB sind auf 1,953,525,168 Sektoren verteilt (512Byte). Ruft man aber die Spezifikationen .pdf Datei auf, dann steht dort klar, dass diese Festplatte bereits mit Advanced Format Technology arbeitet (also doch 4kB Sektoren).

Daher passt die obige Fehlerbeschreibung. 4kB Festplattensektoren sind für derzeitige Linux Systeme der Knaller, denn die Partionierer haben ein ganz anderes (oder besser: altes) Schema im Sinn, so dass sich die Partionsgrenzen überhaupt nicht an die 4kB Ausrichtung halten. Um hier nicht unnötig in Schwafelei auszuarten, kommen nun die zwei wichtigsten Links:

1. Die Erklärung warum das ganze so ein grosses Problem ist.
2. Der Workaround, der einem wieder volle Performance bringt.

Die manuelle Repartionierung mit erneuter Installation brachte den Erfolg. Die ganze Sache hat allerdings nicht nur mir viel Arbeit gebracht, sondern wird noch vielen Leuten Kopfschmerzen bereiten. Die Akteure sehen dabei äusserst schlecht aus, allen voran Western Digital

• WD führt einen durch falsche Hinweise in die Irre (Probleme nur mit Windows XP, andere Betriebssysteme sind ok)
• WD stellt falsche Informationen ins Netz
• WD gibt v.a. die Sektoreninformationen nicht richtig an die nachgelagerten Systeme weiter (BIOS,OS)
• und WD hält es nicht für nötig einen Kernel-/Systemprogrammierer zu beschäftigen der dieses Problem im Voraus unter Linux hätte verhindern können.

Aber auch die Partionierungstools unter Linux sehen schlecht aus.

• v.a. fdisk benutzt das uralte CHS Layout
• auch gparted kann erst in der allerneuesten Version, die Sektoreninformation (soweit sie den von der Festplatte richtig weitergegeben wird, s.o.) in ein vernünftiges Partionierungslayout umsetzen.

Eine historisch begründete Unzufriedenheit mit SUSE Linux Distributionen kommt sicherlich durch den katastrophalen Paketmanager unter SuSE 10.0/10.1 gekoppelt mit Novell’s ZMD und/oder dem stark verbesserten aber noch nicht ganz zufriedenstellenden Paketmanager unter openSUSE 10.2/10.3.

Fairerweise muss man klarstellen, dass dieser Paketmechanismus seit openSUSE 11.0 nun sehr zuverlässig und sehr schnell arbeitet.

Interessanterweise ist das backend das gleiche geblieben. Es handelt sich um libzypp, was das YaST frontend und die Kommandozeilenapplikation zypper bedient. Wie man an im englischen Wikipedia Eintrag nachlesen kann, wurde seit 11.0 der Solver ausgetauscht, was die Performance dramatisch steigerte.

Ich kann das nur für mehrere openSUSE 11.0 Installationen bestätigen – mit 11.2 ist der Paketmechanismus nochmals wesentlich schneller geworden. Zudem können auch kritische Fehler ziemlich schnell behoben werden – am besten auf der Kommandozeile:

zypper refresh

erneuert die Inhalte aller Repositories

zypper verify

Verifiziert die Integrität der Paketabhängigkeiten und schlägt autonom Verbesserungen vor, falls Bedingungen nicht mehr erfüllt werden.

Gerade letzteres benötigte ich, als ein kritisches Update des Paketmanagers selber, durch eine Fehlfunktion des nicht zu empfehlenden SUSE-KDE-Update Applet, schiefging.

Händisch musste ich mit

zypper install

unter zuhilfenahme einer direkten URL zwei Pakete direkt nochmals installieren (mit –force erzwungen) und danach mit zypper verify einen konsistenen Zustand wiederherstellen.