Problems with BFS 0.422

The latest version of BFS has a strange effect on my box here. The first time i got aware of it was when i ran apt-get update (debian way of sync’ing package lists) which worked normal up to the point of reading local package lists from disk. It was horribly slow. Normally, it needs ~5 seconds to complete, this time it ran for several minutes but I/O-utilization was 100% (using top/iotop). And the sound of the disk was different too.

A more repeatable test: dd if=/dev/zero of=dd_disk_test bs=123K count=5000 needed 112 seconds which sums up to 5.6 MB/s – way to slow. The same test with a different disk, a 128 GB SSD had twice the rate, 9.7 MB/s, but way to slow too. No other sign of wrong-doing, everything else was fine. Changing the kernel did the trick. Same Version, linux-3.4.1, but without BFS runs fine: same test completed in 5 seconds (124 MB/s). At the moment i have no glue how to dig into the problem to find the root of it.

/edit: nope, it’s back. After a certain amount of uptime i saw the problem with a vanilla kernel too. (10.6.12)

BFS raus der Warteschleife

Es hat also doch nicht so lange gedauert bis zur Veröffentlichung der BFS-Version, die mit dem 2.6.38er Kernel eingesetzt werden kann. Natürlich läuft der lokale Rechner hier schon mit so einem und tut das sehr gut. Interessanterweise gibt es im oben verlinktem Verzeichnis auch einige weitere Patches, die zeigen, wie das eigene System noch etwas mehr auf Desktop-Bedürfnisse angepasst werden kann. Es gibt schliesslich im Standard-Kernel nicht wenige Annahmen oder Kompromisse, die für embedded-Systeme genauso gelten wie für dicke Mainframe-Kisten oder Cluster.

BFS für 2.6.38 in Warteschleife

Alle letzten Kernel-Versionen liefen hier mit dem BFS, weil einfach der reine Eindruck von Interaktivität immer spürbar besser war. So erscheint es logisch, mit dem Release eines neuen Kernels bzw. einer neuen Version auch nach einem Update des Schedulers zu kucken. Der lässt allerdings auf sich warten. Wie jetzt in Kolivas‘ Blog nachzulesen ist, war er etwas überrascht vom schnellen Release und auch anderweitig mit weiterer Software beschäftigt, weswegen noch keine neue Version auf dem Tisch liegt. Das wird auch noch eine Weile so bleiben, will Kolivas doch erstmal die Auswirkungen des autogroup-Patches beobachten.

Problem mit Schreiben auf externe USB-Platte

Hmm, immer noch keinen Hinweis auf den Verursacher des usb-Schreibraten-Einbruchs hier. Die erste Vermutung mit Laufzeit und Speicherauslastung ist falsch stellt nur einen Teil des Problems dar. Allerdings macht der Prozess-Scheduler einen (riesigen) Unterschied: mit dem speed-king BFS bricht die Schreibrate auf ca. 1 MB/s ein, mit dem Standard-Scheduler CFS geht es „nur“ bis auf 10-20 MB/s zurück. Mittlerweile such ich in die Richtung devkit-disks und gvfsd. Ersterer stürzt hier nach dem Starten (ich hab keine Ahnung, wer den überhaupt startet :/) mit Getöse ab.
Der Artikel lag jetzt schon eine Weile in der Kiste, aber mittlerweile hat sich ein besseres Bild ergeben. Einerseits spielt der Prozess-Scheduler keine wirkliche Rolle, da der Fehler auch mit dem Standard-Scheduler auftaucht. Der Einbruch der Schreibrate muss eine zentralere Ursache haben. Ein kleiner Thread auf der Mailingliste der Kernel-Entwickler deutet darauf hin, dass es mehrere Leute mit diesem Problem gibt. Leider endet die Diskussion dort auch sehr schnell wieder ohne einen Hinweis auf eine mögliche Lösung.