Hilfe von Fuse?

Weiter ging die Suche nach Hilfe bei den Fuse-Entwicklern: Direkt auf der Projektmailingliste besteht die Möglichkeit, Fehler zu melden und nach Ideen für mögliche Patches zu fragen. Auf Basis der Resultate des Debuggings für Launchpad entstand so auch ein Bericht an die Fuse-Mailingliste. Leider erwies sich Fuse nicht als das aktivste Projekt der FL/OSS-Szene: Von wenigen Rückfragen abgesehen kam nicht viel hilfreiches Feedback. Am Ende lief die Diskussion darauf hinaus, dass der Fuse-Treiber von Quobyte wohl das Problem sei.

Das war allerdings auszuschließen: Die ganze Idee hinter Fuse besteht darin, dass Nutzer - auch ohne Rechte des Systemadministrators "root" - eigene Dateisysteme anlegen und nutzen. Selbst wenn ein Fuse-Treiber also einen Bug hätte, dürfte dieser niemals zum Absturz des Host-Systems führen. Richtig war hingegen die Anmerkung der Fuse-Entwickler, dass sie in der Lage sein müssen, den Fehler zu reproduzieren. Sonst sei ordentliches Debugging unmöglich - die Entwickler konnten sich schließlich schlecht selbst ein Openstack aufbauen, um unter gleichen Bedingungen zu testen.

Schwer zu reproduzieren

Das Thema Reproduzierbarkeit war komplexer als zunächst vermutet: Zuverlässig trat das Problem eingangs nur dann auf, wenn Openstack auf KVM-VMs zugreifen wollte, deren virtuelle Festplatten auf dem Fuse-Mount lagen. Zwar war das Openstack-Produkt noch in der Beta-Phase. Dennoch war es keine Option, wahllos virtuelle Maschinen der Beta-Kunden abstürzen zu lassen, um das Problem auf Host-Ebene zu debuggen. Aus diesem Grund war die einzige Maschine mit 4.2 längst aus dem Openstack-Verbund ausgeschieden. Aber außerhalb von Openstack war der Fehler zunächst nicht reproduzierbar: Alle Versuche, direkt auf dem Fuse-Mount ohne Openstack und KVM den Fehler auszulösen, schlugen fehl.

Immerhin war damit der nächste Debugging-Schritt klar: Aufgabe war nun, ein Setup zu bauen, das möglichst klein war und mit Standard-Tools von Ubuntu auskam. Gleichzeitig musste sich das Problem mit diesem Mini-Setup aber auch reproduzieren lassen. Weil der Fuse-Treiber für Quobyte offenbar in der Lage war, das Fehlverhalten auszulösen, war Quobyte selbst der nächste Ansprechpartner.

Quobyte liefert

Mit dem Problem konfrontiert waren auch die Quobyte-Entwickler erst einmal ratlos. Der erste Debugging-Ansatz lief auf das Reproduzieren des Problems mit einem anderen Fuse-Treiber als dem eigenen hinaus: NTFS-3G war das Mittel der Wahl. Nach etlichen Tagen des Debuggings dann der Durchbruch: Auch mit einer aktuellen Version von NTFS-3G trat das Problem auf - wenn der NTFS-3G-Treiber gegen die Version 3 der Fuse-Bibliothek gelinkt ist. Langsam ließen sich Details ausmachen: Der Absturz passierte nur bei asynchronem, direktem I/O-Zugriff (asynchronous direct I/O). Dieser ist erst in Version 3 der Fuse-Bibliothek verfügbar. Die Version 2, die bei allen Distributionen zum Einsatz kommt, unterstützt diese Funktion nicht.

Quobyte war es damit gelungen, eine generische Basis zu schaffen, auf der sich das Problem reproduzieren ließ. Und es war auch klar, dass der Bug sich im Fuse-Modul des Linux-Kernels befindet. Dass es ab hier noch mehr als vier Monate dauern würde, bis der kaputte Code identifiziert sein würde, ahnte zu dieser Zeit noch niemand.

Kernel-Changelogs wälzen

Der nächste Schritt auf der To-Do-Liste war, die Kernel-Version ausfindig zu machen, die als erste nachweislich das Problem hatte. Linux 3.19 arbeitete tadellos, Linux 4.2 nicht mehr. Zwischen den beiden Kernels lagen nur zwei weitere Versionen: 4.0 und 4.1. Linux 4.0 funktionierte wie Version 3.19 wunderbar, Linux 4.1 zeigte das gleiche Verhalten wie der Kernel der Version 4.2. Ein Blick in das Git-Verzeichnis des Linux-Kernels offenbarte, dass es zwischen Linux 4.1 und 4.2 tatsächlich Änderungen am Fuse-Modul des Kernels gegeben hat. In jener Änderung musste also der Grund zu finden sein, der Fuse ab Linux 4.2 reproduzierbar zum Absturz brachte. Linux-Urgestein Christoph Hellwig selbst hatte den Patch eingebracht, der ohne Probleme in den Kernel-Code durchgewunken wurde und dort seit Februar 2015 integriert war.

Wieder ergriff Quobyte die Initiative: In mühevoller und wochenlanger Arbeit fanden die Entwickler dort heraus, dass tatsächlich ein Teil des genannten Patches problematisch ist. Denn unter Umständen greift das Fuse-Modul durch eine falsche Reihenfolge von Funktionsaufrufen auf Speicher zu, den es zuvor bereits wieder freigegeben hat.