Transfluktionale Kernel-Anomalien [Update II]
Seit einer Weile zeigt rtorrent ein seltsames Verhalten: Downloads werden fertiggestellt, die Berechnung des Hashes schlägt fehl und der Download stoppt. Da – zumindest laut syslog – keine Laufwerksfehler aufzutreten scheinen, ist das nicht weiter schlimm, der Download muss einfach neu gestartet werden und wird dann zu Ende geführt. Es nervt halt.
Ich hab die Probleme zunächst auf die aktuelle rtorrent-Version geschoben, nun scheint die Lösung aber im Kernel zu liegen: Ein Bug in Kerneln nach 2.6.18.3 zerstört in bestimmten Konstellationen (SMP und preemptive kernel) Daten, dummerweise liefern einige Distributionen (etwa Ubuntu Feisty) genau diese Konstellation aus. Ein 2.6.19-6-generic in Ubuntu-Konfiguraton reicht aus, um das Problem zu triggern, ein selbstgebauter 2.6.20-rc1-mm1 auf einer Dual-Core-Maschine (also mit aktiviertem SMP) auch. Ich habe Anzeichen dafür gefunden, dass auch ein 2.6.17-10-generic von Ubuntu Edgy im Zusammenspiel mit rtorrent 0.5.3-1/libtorrent 0.9.3-1 ähnliche Fehler produziert, muss dem aber noch weiter nachgehen.
In Kernelversionen nach 2.6.17 ist generell irgendwo der Wurm drin. Seitdem S-ATA nicht mehr unter SCSI läuft (siehe 2.6.19), ist der P-ATA-Port an meinem Promise FastTrak 378 mal wieder nicht nutzbar, mit allen Kernel-Versionen zwischen 2.6.19 und 2.6.20-rc1-mm1 friert der komplette Rechner ein wenn “zu viele” Daten (~4 GB) via Kernel-NFS übertragen werden. Software-RAID-Konfiguration en(mdadm) von 2.6.17 und 2.6.19 werden untereinander nicht erkannt, ich kann sogar unter der einen Kernel-Version den Superblock einer Partition löschen (mdadm –zero-superblock) und der “andere” Kernel findet scheinbar doch wieder einen Superblock (wahrscheinlich an anderer Stelle).
Einigen Releases müsste man die “stable”-Markierung IMO grad wieder entziehen.
Update: Die Sache ist schlimmer als zunächst erwartet. KernelTrap fasst den aktuellen Stand zusammen, demnach hat Linus Torvalds ein Test-Programm geschrieben, welches den Fehler zuverlässig provoziert. Damit wurde bisher aber lediglich festgestellt, dass die Wurzeln bis zum Kernel 2.6.5 zurückreichen, die Fehlerquelle an sich ist aber nicht gefunden – sie tritt nur anscheinend in aktuellen Kerneln mit einer höheren Wahrscheinlichkeit auf. Torvalds wendet sich mit folgenden Worten an die restlichen Entwickler und die Userschaft:
” I now seem about to trigger it with a 100MB file on a 256MB machine in a minute or so, with this slight modification. I still don’t see _why_, though. But maybe smarter people than me can see it.”
Das Debian-Projekt hat den Bug mittlerweile sogar explizit als Release-Stopper der kommenden Version 4.0 (“Etch”) genannt.
Update II: Wie es aussieht wurde der Bug nun gefunden und gelöst.