Ilja Dryomov hat darauf hingewiesen, dass einige Patches für Access Control Lists (ACL) im Kernel stecken, die einander widersprechen. Besonders sei das bei Ceph der Fall, dem verteilten Dateisystem seines Arbeitgebers Inktank. Er schickte ein Patch ein, das für Einklang sorgt.

Als sich Linus Torvalds den betreffenden Code im Virtual File System (VFS) genauer ansah, entdeckte er ein weiteres Problem: Einige ACL-Funktionen reichten die Informationen über Dateien als »dentry« -Struktur weiter, als Pointer auf den Inode einer Datei auf der Festplatte. Bei einem verteilten System wie Ceph sind aber nur Dateipfade sinnvoll, denn dort sind mehrere Festplatten mit ihren Inode-Nummern im Spiel.

Linus beauftragte Al Viro und Christoph Hellwig herauszufinden, ob es eine saubere Methode gibt, den Dateipfad aus der Inode-Nummer zu ermitteln. Christoph berichtet, die Funktion »set_acl()« ließe sich leicht ändern, »get_acl()« aber nicht. Linus, der Letztere selbst geschrieben hatte, meinte: “Stimmt. Es ist ein totaler Alptraum, den Dentry-Pointer durch die ganze Kette zu verfolgen. Verdammt.” Er schlug vor, die Ceph-Entwickler sollten für ihren speziellen Anwendungsfall die Umrechnung selbst umsetzen.

Christoph wies darauf hin, dass das Problem nicht nur Ceph betreffe, sondern beispielsweise auch das Plan9–Dateisystem oder CIFS. Nun produzierte Linus doch ein Patch, das die Dateipfade weiter unten in der Kette von Aufrufen implementiert.

Al Viro gefiel der Code überhaupt nicht. Seiner Meinung nach enthielt das Patch eine Menge überflüssigen Code. Insbesondere fand er, Linus führe Sonderfälle ein, wenn ein schlichter Inode ausreichen würde.

Torvalds hielt dagegen, es gehe darum, Inodes zu vermeiden und dafür Dateipfade zu verwenden. Er erklärte: “Manche Netzwerk-Dateisysteme übergeben dem Server den Pfad. Und jede Operation, die etwas auf dem Server nachsehen möchte, braucht den Dentry, nicht den Inode.”

Al hielt das Problem für einfacher lösbar als Linus. Er argumentierte, ein Dateisystem wie CIFS kenne keine Hardlinks. Zu seiner Überraschung erklärten Christoph und Linus, CIFS unterstütze tatsächlich Hardlinks. Da dämmerte es Al: “Richtig: bei Samba auf einem Unix-Server.”

Linus Torvalds erklärte, welche Rolle die Hardlinks bei einem Netzwerk-Dateisystem spielen: “Lege in zwei verschiedenen Verzeichnissen je einen Hardlink an. Anschließend stellst du die Berechtigungen des einen Verzeichnisses so ein, dass man es nicht betreten kann. Dann versuchst du, die Berechtigungen desselben Inode über beide Pfade auszulesen. Du erhältst unterschiedliche Ergebnisse. […] Damit wären bei einem Zugriff per Netzwerk-Dateisystem die zwei Pfade zum selben Inode nicht äquivalent.” Das überzeugte Al Viro schließlich und Linus konnte sein Patch einreichen.

Experiment à la Torvalds: Die Hardlinks »/dir1/link1« und »/dir2/link2« zeigen auf denselben Inode, sind aber per Samba/CIFS unterschiedlich gut erreichbar.

Andy Lutomirski, Kernelentwickler aus der Finanzbranche, möchte das Testen von Kerneln in virtuellen Maschinen vereinfachen. Zu seinem Projekt namens Virtme hat ihn das schwierige Testsetup mit KVM motiviert. Er schreibt: “Um eine Änderung am Kernel zu testen, musste ich ein Disk-Image auftreiben, mir die Qemu-Beschwörungen zum Booten merken und fluchte schließlich laut, weil das Initram-FS meine virtuelle Festplatte nicht fand. Weitere Flüche folgten, weil es so schwierig ist, Dateien zwischen Host und Gast auszutauschen.”

Das Projekt begann bereits 2010 mit Skripten für den Eigenbedarf, die Andy schrieb, als Virt-FS erschien. Nun sind sie als Virtme unter https://github.com/amluto/virtme erhältlich, das derzeit aber nur auf Fedora 20 läuft. Die Software erledigt alle Arbeiten, die zum Einrichten einer bootfähigen Umgebung samt einigen Testwerkzeugen nötig sind.

Daneben beschreibt Andy seine weitere Roadmap für die Software. Sie sieht unter anderem das automatische Ausführen von Skripten in der virtuellen Maschine vor. So könnte man beispielsweise eine Testsuite ausführen und die Ergebnisse sammeln, ohne einen Finger zu rühren – abgesehen von dem Kommando, um das System zu starten.

Borislav Petkov hat die Beschreibung der Option »CONFIG_DEBUG_INFO« in der Kernelkonfiguration geändert. Er warnte Anwender, dass sie “gewaltigen Bloat” erzeugt und den Build in die Länge zieht. Der Google-Entwickler David Rientjes bemängelte, dass diese Beschreibung nicht erklärt, was mit dem Bloat gemeint sei. Er wies darauf hin, dass die Datei »vmlinux« beispielsweise dadurch nicht größer wird.

Linus Torvalds wandte ein, die Objektdateien würden merklich größer, beispielsweise sei bei ihm die Datei »fs/built-in.o« ohne die Option 2,8 MByte groß, mit ihr (und »CONFIG_DEBUG_INFO_REDUCED« ) habe sie aber 11,8 MByte. Er schrieb: “Die viel größeren Objektdateien machen vor allem auf Laptops Ärger, die in der Regel weniger Speicher und schwächere I/O-Systeme haben.”

Andrew Morton gab ihm recht und berichtet, er schalte die Option grundsätzlich ab, wenn er den Kernel mit »allmodconfig« baue, also alle sonstigen Optionen aktiviere. Er schlug zudem vor, die Beschreibung der Option solle klar machen, dass sie zwar zur Build-Zeit größere Dateien bewirke, nicht aber zur Laufzeit. Diese Fassung gefiel auch Borislav besser und er wollte schon ein aktualisiertes Patch einschicken.

Da wandte David ein, dass »CONFIG_DEBUG_INFO_REDUCED« das Aktivieren der anderen Option voraussetze. Er fragte die Runde, ob man die beiden Optionen voneinander entkoppeln solle.

Daraufhin meldete sich Ingo Molnar und schlug vor, eine ganz neue Option einzuführen, die den Kernel ohne Debugging-Informationen in den Objektdateien übersetzt. Linus dagegen meinte, etwas Ähnliches gebe es bereits mit »COMPILE_TEST« – einer Option, die nur zum Testen des Übersetzungsvorgangs gedacht ist, nicht zum Ausführen der Resultate. Der Kernel-Chef schrieb also ein Patch, das »CONFIG_DEBUG_INFO« nur erlaubt, wenn man »COMPILE_TEST« deaktiviert.

Nur der deutsche Intel-Entwickler Andi Kleen hatte noch einen Einwand: Er lasse manchmal tatsächlich die Binärdatei aus einem »allyesconfig« -Build laufen, um Statistiken zu erstellen. Linus fand diesen Anwendungsfall aber so exotisch, dass er Andi riet, die Build-Dateien von Hand anzupassen. (Zack Brown/mhu)