Ich war mir sowas von sicher, das mir irgendwer 200GB unterschlägt - sei es fdisk, cfdisk, sfdisk, parted, das Rescue-System, grml, Ubuntu, denn statt 500GB war die letzte Partition nur 300GB groß. Hat der Kernel vielleicht eine falsche Geometrie erkannt? Gibt es irgendwo ne Grenze, so wie damals bei den 1024 Zylindern?

Nach einen halben Tag verzweifelten suchen fiel es mir dann beim Blick auf das Kickstart-File wie Schuppen von den Augen: die zweite Partition war nicht 20GB, sondern 220GB groß. Klarer Fall von selektiver Wahrnehmung. Autsch!

Posted: Juli 31st, 2008 under Linux.
Comments: none

Mittlerweile kann ich sagen, das sich die Probleme mit dem forcedeth-Treiber gelegt haben. Selbst bei dauerhaften Netzwerk-Verkehr im Gigabit-Bereich und den entsprechenden Festplatten-IO bleibt alles ruhig. Ausschlaggebend war der Boot-Parameter pci=nomsi und die massive Anhebung des Modul-Parameters max_interrupt_work auf 120.

So gut, so schön. Eine Sache bleibt aber noch: der Boot-Parameter pci=nomsi scheint die Wunderwaffe für allerlei Wehwehchen des Linux-Kernels zu sein. Und was ist MSI?

Message Signaled Interrupts, in PCI 2.2 and later and PCI Express, is an alternate form of interrupt from the traditional pin-signalled system; instead of asserting a given IRQ pin, a message is written to a segment of system memory. Each device can have from 1 to 32 unique memory locations in which to write MSI events to. An advantage of the MSI system is that data can be pushed along with the MSI event, allowing for greater functionality.
Wikipedia.org

Der Linux forcedeth-Treiber scheint damit wohl Probleme zu haben und dann schaltet man es eben ab. Ein besserer Treiber wäre mir lieber.

Posted: Juli 28th, 2008 under Linux.
Comments: 1

Ich hatte heute eine kurze Diskussion darüber, woran man erkennt, das ein Server ausgelastet ist. Liegt es an der CPU-Auslastung? Load von 1 per CPU? Interrupts? Context Switche? IOWait? Averade Service Time? Swap? Vorschläge sind erbeten.

Posted: Juli 21st, 2008 under Linux.
Comments: 18

Manche Ergebnisse scheinen von vornherein so klar zu sein, das man kaum einen Gedanken daran verschwendet auch mal zu hinterfragen, ob man nicht doch falsch liegen könnte. Ich war zum Beispiel fest der Meinung, das der NOOP IO-Scheduler auf einen Raid-Controller mit 256MB Cache am meisten Performance bringt. Schließlich bietet der Controller eine eigene Logik, sowie Zwischenspeicher und weiss damit am besten wie er die Blöcke auf die Platten bringt. Eine vorgeschaltete Logik im Kernel wäre da nur kontraproduktiv.

Nach ein paar Messungen auf einen RAID-10 mit vier 146GB 10K Festplatten bin ich klüger. Von den drei getesteten IO-Schedulern NOOP, CFQ und DEADLINE war (bis auf einen Wert) der CFQ-Scheduler am schnellsten. Selbst der DEADLINE-Scheduler konnte mit NOOP oft mithalten, ganz davon abgesehen das die Werte aller Drei nicht allzuweit auseinanderlagen.

Posted: Juli 16th, 2008 under Linux.
Comments: 1

Mark Shuttleworth im Interview:

So one option that we considered was: “Let’s not call 8.04 the LTS, let’s call 8.04.1 the LTS”

Kurzer Augenblick der Einsicht - aber nur ein ganz kurzer.

Posted: Juli 14th, 2008 under Ubuntu, Zitate.
Comments: none

Das Thema CPU Frequency Scaling ging ja eine Zeitlang durch alle Blogs und Foren. Mittlerweile ist das Normalitäet und funktioniert auch gut. Ist das Wirklich so? Ich habe da so meine Zweifel.

Auf Single- und Dual-Core Systemen tut es tatsächlich wie erwartet, aber auf Systemen mit mehreren CPU-Sockeln habe ich nun schon mehrfach erlebt, das das Scaling das System ausbremste, weil CPUs unterschiedlich getaktet waren. Trotz steigender Last takteten die Cores auf der einen CPU nicht wieder hoch und irgendwann war die Load so hoch, das ein Arbeiten nicht mehr möglich war. Erst das Abschalten des Daemons brachte das System wieder auf den richtigen Weg. Ähnlich sieht es mit iowait aus auf die das Scaling ebenfalls nicht reagiert. Also im Zweifel besser immer ausschalten.

Posted: Juli 11th, 2008 under Hardware, Linux.
Comments: 1

Es gibt Netzwerk-Hardware unter Linux von der sollte man die Finger lassen. Karten mit RTL- oder VIA-Rhine Chipsätzen können funktionieren - müssen es aber nicht. Genauso sieht es mit Nvidia-Chipsätzen aus, dessen forcedeth-Treiber eine richtige Schneise durch Linux-Foren gezogen hat.

Intressanterweise gibt es Server-Hersteller, wie z.B. Sun, die so etwas verbauen. Deren ersten Opteron-Server hatten noch vier e1000-Karten für die es imho die besten Treiber gibt die man unter Linux haben kann. In der folgenden M2-Serie gab es dann zwei Nvidia und zwei e1000 Karten, eine Entscheidung für die Sun (zu Recht) ordentlich Prügel eingesteckt hat. Man gab sich geläutert und versprach zukünftig das Mixen zu lassen. Wer nun denkt es gäbe wieder vier e1000-Karten liegt falsch, denn z.B. die X4240 hat vier Nvidia-Karten, womit der Spass selbst unter dem supporteten RHEL losgehen kann.

Sun wurde wohl schon selbst davon getroffen, denn in den Server Product Notes gibt es den schönen Eintrag Heavy, Sustained Disk and Network I/O Might Cause Server to Hang or Display “Soft Lockup” Message, der aber nur eine mögliche Fehlermeldung beschreibt. Viel Bekannter dürfte die hier sein:

too many iterations (6) in nv_nic_irq

Damit muss der Spass aber noch nicht Zuende sein, denn an kann nämlich auch noch

kernel: NETDEV WATCHDOG: eth0: transmit timed out
kernel: eth0: Got tx_timeout. irq: 00000037
kernel: eth0: Ring at 1213a2000
kernel: eth0: Dumping tx registers

sehen. Danach ist die Netzwerkkarte tot. Tja und nun kann man Anfangen zu raten. Das Internet ist voll von Lösungsansätzen, die aber alle nicht wirklich passen wollen. Ich hab fürs Erste das tcp segmentation offload des Treibers mit

ethtool -K eth0 tso off

abgeschaltet. Seitdem ist Ruhe - fragt sich nur wie lange und ich kann in der Zwischenzeit mal darüber nachdenken, warum Sun die Nvidia-Netzkarten für eine gute Lösung hält.

Update: Nö, hilft nix. Notfalls kann man im laufenden Betrieb rmmod forcedeth; modprobe forcedeth machen, dann spart man sich einen Neustart.

Posted: Juli 3rd, 2008 under Allgemein.
Comments: 5

Ich bin kein Novell Fan. Das hat damit zu tun, das sie bis jetzt alles (mit Ausnahme Netware) was sie angepackt haben in den Sand gesetzt haben. Sei es Unix oder WordPerfect - sie haben es gekauft, keine Ahnung gehabt was sie damit anfangen sollen und wieder fallen gelassen. Kaputt gespielt würde ich sagen. Ähnlich sieht es mit Suse Linux aus. Ich bin wohl nicht der einzige der so denkt:

First the good news. OpenSUSE has retained some of the good features it had back in the days when it existed as just one avatar - SuSE Linux. You can’t strip away all the good oil in five years, even if you are a company like Novell.
iTWire

Den einzigen Lichtblick welchen ich sehe ist das Novell Suse nicht fallen lassen kann. Sie können nicht zurück zu Netware, denn das ist Mausetod. Novell ist zu klein um sich ein eigenes, propritäres OS leisten zu können (genau wie Sun übrigens) und so kaufte man sich ein offenes Betreibssystem, versucht es mit dem Open Enterprise Server (dessen Hauptbestandteile nicht offen sind) wieder ein Stück zu schließen, sucht den Schulterschluss mit Microsoft und eiert seit Jahren ohne erkennbare Strategie in der Welt herum.

Posted: Juni 28th, 2008 under Allgemein.
Comments: 2

Wenn mich nicht alles täuscht gab es seit meinen letzten Rant täglich Updates, sogar einen neuen Kernel. Unstable my Ass. Und ja, Ubuntu wird immer mehr zum neuen Windows. Letztens hab ich mich noch über den Neustart von Windows lustig gemacht, den das Acrobat Reader Update erforderlich machte. Heute gabs bei Ubuntu ein neues OpenSSL und die fordern mich tatsächlich penetrant dazu auf meinen Rechner neu zu starten *vogelzeig*

Posted: Juni 26th, 2008 under Linux, Ubuntu.
Comments: 8

Vorgestern war dieses Serverchen mit dem Dist-Upgrade auf Debian Lenny dran. Hat, alles in allem, etwa eine Stunde gedauert. Source-File anpassen, Dist-Upgrade laufen lassen, neuen Kernel installieren, Neustart, dpkg-old und dpkg-new abarbeiten - fertig. Zwei Dinge gab es danach: bei SpamAssassin funktionierte die Bayes-DB nicht mehr und Mysql warf Fehlermeldungen beim Neustart. Beim ersteren lag es am Spamass-Milter, der unter einer neuen UID läuft. Bei Mysql bin ich mir nicht sicher.

ERROR 1064 (42000) at line 1: You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the
right syntax to use near '-seemann_de.sk2_blacklist' at line 1

Zudem habe ich, nach dem Fedora 9 Desaster den Desktop platt gemacht und Kubuntu Hardy installiert. Hat keine Stunde gebraucht bis man damit arbeiten konnte - feels like home.

Posted: Juni 5th, 2008 under Debian, Linux, Ubuntu.
Comments: none