Pinguinscheisse der gesammelte Tux-Dreck dieser Welt

Vielleicht könnte man bei LInux auch sagen: NFS, die unendlich dämliche Geschichte.

Der Admin an und für sich ist leidensfähig, wenn er alt ist, sonst wird er als Admin nicht alt. Einen Sun NFS-Server kann man ruhig booten und danach läuft alles weiter, aber Sun gibt’s nicht mehr. Einen Linux NFS-Server kann auch auch booten, loggt sich danach ein, startet „exportfs -f“ und ab dem Moment läuft auch wieder alles weiter. Aus irgendeinem Grund tut’s das nicht automatisch im Startskript des NFS-Servers. Man muss das später machen. Ansonsten melden die Clients „stale file handle“, und sofern es Linux-Clients sind, hilft weder ein umount (schon deswegen, weil es auch mit -f nicht geht) und auch kein reboot. Also wie gesagt, man weiss das ja.

Und deswegen hat man sich was Neues einfallen lassen: Der rpc.nfsd schaltet in seiner aktuellen Version per default kein NFSv2 mehr ein, was nicht im Manual steht. Wenn man nur genug sucht, sieht man das in /proc/fs/nfsd/versions. Linux andererseits mountet per default alles mit NFSv2, insbesondere das rootfs bei plattenlosen Systemen. Tut man nichts, geht einfach gar nichts mehr, aber ohne irgendeine Fehlermeldung. rpc.mountd hat damit nämlich keine Probleme. Der Kernel kann an sich ja NFSv2, es ist halt nur nicht aktiv.

Die Distributionsentwickler haben das freilich schon gemerkt: Die starten den Kernel mit einem miniroot Image und mounten dann das rootfs aus einem laufenden System heraus. Ein „-V 2“ beim Start des NFS-Servers oder ein „,vers=3“ im rootpath hätte es auch getan. Andererseits wird es mit dem miniroot Image erheblich komplexer, was man (nicht nur bei Linux) gerne Fortschritt nennt.

Vielleicht war die Beschriftung der Ethernet Interfaces keine gute Idee. Bei einem früheren Kernelupdate musste ich die Klebeschildchen schon abknibbeln und vertauschen, weil der neue Kernel die Interfaces anders nummerierte.

Was einmal Spass machte, wird gerne wiederholt: Von 2.6.20 auf 3.5. Der neue Kernel startet, aber irgendwie funktioniert das Netzwerk gar nicht mehr. Kein Wunder, eth0 und eth1 sind schon wieder vertauscht. Einmal die Kabel anders herum stecken, schon geht wieder alles.

Ob die Firma Brother an der Kernelentwicklung teilnimmt? Andererseits bemerkte ein Ex-Kollege gerne: Unterstelle keine Absicht, wenn Dämlichkeit die Sache auch erklären könnte.

Michael

Linux und NFS war schon immer so eine Sache, aber irgendwann in der 3.4 Kernelserie wurde es spürbar schlechter. Und so kommt es, dass ein 3.4.4 es nicht mehr schafft, mit root FS auf NFS zu starten, was z.B. mit 3.1 noch funktionierte: Der Pinguin fällt schon auf den fetten Bauch, noch bevor er richtig losrennen kann.

Es ist bei Fieber typisch, dass die wahrgenommene und die gemessene Temperatur arg abweichen und das F edervieh macht da keine Ausnahme.
Wie warm es ist ihm denn heute? Gute Frage, denn wie findet man das heraus?

Die Antwort ist jedes Jahr eine Andere: Fragen wir doch lm_sensors. Ach nee, das gibt’s ja nicht mehr. An I2C Devices herumzuspielen gehörte sowieso in den Kernel. Also schauen wir mal in /sys/bus/i2c/devices/. Ja, das ist jetzt blöd, denn da kommt man ACPI in die Quere, was es mitunter nicht lustig findet und das System crasht. Ok, schmeissen wir den Treiber wieder raus. ACPI kann man auch direkt in /proc/acpi/thermal_zone/*/temperature befragen – wenn es das kann, und das kann beileibe nicht jedes System, auch wenn es intern dem I2C Treiber in die Quere kommt. Ist aber auch egal, der Kram hatte in /proc nichts zu suchen und das Skript zur Abfrage der Temperatur ist eh noch zu kurz, darum waren die Developer wieder aktiv. /sys/devices/platform/ ist doch mal ein guter Ort, um die Temperatur der Cores rauszukriegen – aber nicht die des Boards. Was hat ACPI auch mit der Plattform zu tun, nur weil es integraler Bestandteil von BIOS und Board ist? Das ist Software und damit virtuell, also /sys/devices/virtual/thermal/thermal_zone0/temp. Jetzt endlich sieht das Skript so richtig fies aus, was mit allen Kernels klarkommt.

Eigentlich wollte ich ja auch nur wissen, wie warm es dem Vieh so ist. Ja, seltsame Sache, ab Mitte Dezember war’s ihm auf einmal locker 20 Grad wärmer. Ach so, das war nach dem Kernel Update von 2.6.34 auf 2.6.36.2. Dolle Sache, mehr Strom braucht das System nicht. Wie auch, Frequency Scaling tat’s vorher schon nicht. Jedenfalls blieb es dem Federvieh auch bei 2.6.37 und 2.6.39 warm. Ende Juli gab es dann 2.6.39.3, weil irgendwer in 2.6.39 den Floppytreiber ruiniert hatte, was ganz ohne Tests keiner merkte. Und damit war das Fieber vorbei, die Temperatur war wieder wie bei 2.6.34.

Also ein halbes Jahr Fieber. Verständlich, dass Linux noch etwas schwach auf den Beinen ist.

Nach getaner Arbeit friere ich meinen ja immer ein. Und ich dachte immer das macht dem Tux nix. Is‘ aber nicht so. Nach 15 Tagen einfrieren und wieder auftauen war der einfach nicht mehr gut drauf. Leichte Lähmungserscheinungen und verlangsamte Reaktionen. Vielleicht nicht ganz aufgetaut? Na gut, ein Putenschnitzel wäre nach 15-mal einfrieren und auftauen wohl auch ungenießbar.

Symptome: Firefox hing immer mal ein bisschen (für 1-2s), aber auch andere Programme ruckelten so vor sich hin. Ob jetzt die Oberfläche (X, compiz, GNOME, XUL), oder das Netzwerkinterface Gefrierbrand hatten, kann ich nicht sagen. Jedenfalls ist jetzt nach einem kompletten Neustart wieder alles knackig und frisch. Bis zum nächsten Mal…

Somit konnte das Federvieh ein weiteres Mal die Qualitätsvorgaben des Marktführers egalisieren. Auch mit den Fenstern muss spätestens nach einer Woche mal kräftig durchgelüftet werden. Ansonsten läuft man Gefahr, dass laufende Dienste schimmelig werden.

Man nehme: Einen kleinen Tux an einem großen NFS-Futterkasten.
Den Tux läßt man nun fleißig lesen und schreiben. Und dabei schaut man zu, wie der Speicher weniger wird, und weniger wird, und noch weniger wird, bis irgendwann der Out-Of-Memory-Killer Amok läuft und die Prozesse ruiniert. Oder der Swapspace fängt an zu ackern.
Das Ende ist dann jedenfalls nahe.

Wenn das mit einem neueren Kernel (2.6.36.x, 2.6.37) passiert, könnte es sein, daß der Kernel einfach Caches für NFS belegt, und die dem Userspace zuschlägt, damit man das mit „free“ nicht sieht. Der Tuxhalter liebt doch Herausforderungen.

Die Abhilfe ist so einfach wie schräg:

sync
echo 2 >/proc/sys/vm/drop_caches


Und schon hat man auf einmal wieder 1-2 Gigabyte Speicher zurückerhalten. Ist das nicht … „toll“?

/dev/* war gar nicht schlecht. Drum habe ich es lange behalten. Die Idee hinter devfs war ja nicht verkehrt, den Kernel Devices selber anlegen zu lassen.  Schon damals ging das Elend los, bestehende Konventionen einfach über den Haufen zu werfen. Read the rest of this entry »

Reboot tut dem Federvieh bekanntlich oft gut, aber seinem Software RAID nicht unbedingt, wenn man beim Booten sowas sieht:

md: kicking non-fresh sdc9 from array!

Und schon ist die Redundanz dahin. Es ist zu vermuten, dass beim Shutdown Daten verloren gingen. Blöd ist, wenn die andere Platte im RAID1 jetzt ein Problem hat und die Synchronisation nicht mehr läuft. Aber wer Software RAID hat, der hat auch ddrescue – für den routinierten Admin kein Grund, die Katastrophe auszurufen und die letzten Änderungen durch Einspielen eines Backups zu vernichten.

Das „kicking“ bringt mich beim Anblick des fetten Pinguins aber auf eine Idee…

Flow control, das war doch diese ganz einfache Sache, wo RTS und CTS gekreuzt sind, und jeder mit RTS signalisiert, wenn er Zeichen annehmen kann, und sein Partner das über CTS sieht, richtig?

Nichts ist einfach, nie. Das war mal so, als UARTs noch keine FIFOs hatten, zu Zeiten des 8250 und des 16450. Hat gut funktioniert.

Dann kam der 16550 und der Pinguin liebt die FIFOs. Der Drecksgeier macht sich keine Gedanken, was mit flow control passiert, wozu auch? Gibt’s da draußen noch was Anderes außer PCs?

Also prüft er CTS, bevor er Zeichen in den FIFO schiebt. Wenn das Gegenüber dann RTS setzt: Was soll’s, der FIFO leert sich weiter. Sicher, wenn der UART nicht hirntot wäre, könnte er selbst mit RTS und CTS spielen. Ist er aber, also wäre es des Pinguins verdammte Pflicht, den Sende-FIFO nicht per Default zu aktivieren, sondern nur, wenn der Admin es ihm mitteilt, weil er weiß, dass die Gegenseite es abkann, wenn RTS erst 16 Zeichen später wirkt.

Da läßt das Vieh aber einen drauf und erlaubt nicht mal, den FIFO abzuschalten.

Hör mal zu, Du Federvieh: Wegen Dir hat ein kleiner single board computer jetzt einen 16550 bekommen müssen und die 16450 Chips kann ich wegwerfen. Aber man sieht sich immer zweimal im Leben…

Der Admin legt ein paar MD RAID1 Gruppen an und dann passiert es: Eine Platte geht kaputt. So kaputt, dass Linux das Device entfernt. Aber warum sollte es das den MD-Devices mitteilen? Dort ist eine failed disk Teil der Gruppen, die man jetzt nicht mehr entfernen kann, weil es sie ja nicht mehr gibt. Reboot tut gut, anders wird man den Zustand nicht los.

Sollte es sich die defekte Platte überlegen und wieder am SATA-Bus erscheinen, dann bekommt sie einen neuen Namen, d.h. sdc wird wegen Defekt entfernt und dafür erscheint die gleiche Platte danach als sdm – sdc bleibt verschwunden – bis zum nächsten Reboot.

Sicher, Platten sollten sowas nicht tun, aber wenn der Drecksgeier schon Devices entfernt, statt jeden Zugriff mit EIO zu beantworten, dann sollte er es komplett tun.