Der Linux-Kongress 2010 in Nürnberg
Der 17. Internationale Linux-Kongress fand zum zweiten Mal nach 2006 in Nürnberg statt. Dieser Artikel gibt eine Übersicht über die Themen und Vorträge.
Zweiter Konferenztag: Freitag, 24. September
Der Freitag begann schon um 9.30 Uhr mit weiteren Vorträgen. »The New Linux 'perf' Tools« (PDF-Datei) von Arnaldo Melo war ein interessanter Einführungskurs in die ständig wachsenden Möglichkeiten des Programms perf. Aufbauend auf der noch jungen perf-Infrastruktur des Kernels werden detaillierte Einblicke in das Laufzeitverhalten des Kernels möglich, wobei es zahlreiche Filtermöglichkeiten sowie Ausgaben gibt, die an top oder strace erinnern. Zugleich ist perf das erste Tool, das gemeinsam mit den Kernel-Quellen gepflegt wird. Für die Kernel-Entwickler ist dies ein Experiment, um zu sehen, ob das Hinzufügen von Tools zum Kernel sinnvoll ist. Zudem verwendet perf Teile des Kernel-Codes in Benutzerprozessen, es ist daher nicht nötig, zwei verschiedene Quellcodes zu pflegen. Bis jetzt sieht der Versuch sehr erfolgreich aus.
Mikulas Patocka referierte parallel dazu über »Shared snapshots« (PDF-Datei). Dies ist eine neue Implementierung von Snapshots für den Logical Volume Manager (LVM). Die aktuelle Snapshot-Implementation arbeitet nicht effizient. Die neuen »Shared snapshots« sollen dies ändern und zahlreiche Limitierungen aufheben. Es wird auch möglich sein, Snapshots von Snapshots zu machen. Damit lassen sich z.B. virtuelle Maschinen sichern, die ihrerseits aus Snapshots von anderen virtuellen Maschinen initialisiert wurden.
Nach der Kaffeepause stellte DRBD-Erfinder Philipp Reisner libtcr, die Threaded Coroutine Library, vor (PDF-Datei). Diese Bibliothek ist für Server gedacht, die Anfragen nicht nur parallel mit leichtgewichtigen Threads verarbeiten sollen, sondern auch die einzelnen Phasen der Bearbeitung auf verschiedene Threads aufteilen sollen. Dieses Schema führt zu hoher Effizienz, da die Arbeit auf alle Prozessoren eines Systems verteilt werden kann und die einzelnen Prozessoren mit hoher Cache-Lokalität betrieben werden. Der parallele Vortrag »Tracking filesystem modifications« (PDF-Datei) von Jan Kára war ebenso interessant. Viele Anwendungen benötigen Informationen, was sich im Dateisystem geändert hat, und das möglichst effizient. Ursprünglich besaß Linux keine solche Möglichkeit, Anwendungen konnten allenfalls die Verzeichnishierarchie durchlaufen und die Änderungszeit der Dateien auslesen - sehr ineffizient. Im Laufe der Zeit wurden Dnotify (inzwischen obsolet) und Inotify zum Kernel hinzugefügt. Beide haben Probleme, wie Jan Kára erklärte. Der neueste Ansatz ist jetzt Fanotify, das erst in Linux 2.6.36 erscheinen wird. Es wird Inotify vorerst nicht ersetzen, sondern stellt zusätzliche Funktionalität bereit. Die Zukunft wird möglicherweise eine Vereinheitlichung von Inotify und Fanotify bringen, doch das ist noch offen, zumal auch Fanotify Probleme aufweist, beispielsweise die unbegrenzte Länge der Ereignis-Warteschlangen, die den Speicher füllen könnte. Danach ging Kára auf ein spezielles Feature von btrfs ein, das mit dem Kommando
btrfs subvolume find-new eine effiziente Lösung bereitstellt, die allerdings noch verbessert werden muss. Den Abschluss bildete ein eigener Vorschlag des Referenten, zu jedem Verzeichnis ein Flag und einen Zeitstempel für die letzte Änderung einer Datei in diesem Verzeichnis zu halten. Mit diesen »rekursiven Zeitstempeln« könnte die Suche einer Anwendung nach geänderten Dateien stark beschleunigt werden, allerdings nur, wenn die Verzeichnisse relativ wenig Dateien enthalten. Einen Prototyp, der erweiterte Dateisystemattribute nutzt, hat Kára bereits geschrieben.In »Log2fs or how to achieve 150.000 IO/s« (PDF-Datei) stellte Jörn Engel seinen Nachfolger von logfs, log2fs, vor. Der neue Name wurde wegen der Änderung des Disk-Layouts fällig, diese wiederum war aus Sicht des Entwicklers nötig, um log2fs auf SSDs mit der maximal möglichen Geschwindigkeit laufen zu lassen. Olaf Dabrunz hingegen widmete sich in »Universal Function Call Tracing« (PDF-Datei) dem Problem des Tracings von Anwendungen. Die bekannten Tools strace und ltrace haben Limitierungen: Ersteres setzt auf ptrace auf und kann daher nur Systemaufrufe zeigen, letzteres nutzt Tricks mit dynamischen Bibliotheken und funktioniert nicht mit internen Funktionen, die nicht exportiert werden. Das Tool fctrace, das gerade in Entwicklung ist, soll diese Begrenzungen überwinden. Es setzt auf die im Kernel schon vorhandene kprobes-Infrastruktur auf.
Nach der Mittagspause folgte der Vortrag, den ich mit größter Spannung erwartet hatte: »systemd« (PDF-Datei) von Lennart Poettering. Der Vortrag konnte leider den hohen Erwartungen nicht gerecht werden. Viel Neues war nicht zu erfahren, die Präsentation beschrieb im Wesentlichen das, was Pro-Linux bereits berichtet hatte. Dass die Einführung von systemd in Fedora auf Version 15 verschoben wurde, war auch schon nichts Neues mehr. Poettering betrachtet die Entwicklung von systemd schon als weitgehend abgeschlossen, das System muss eben noch weiter stabilisiert werden. Mit systemd verschwindet der Großteil des Shell-Codes aus der Bootphase. Dadurch geht etwas Flexibilität verloren, aber wer diese unbedingt braucht, laut Poettering wahrscheinlich weniger als 1% aller Nutzer, kann beim bisherigen Init-System bleiben. Der Shell-Code konnte durch eine sehr kleine Zahl von C-Programmen ersetzt werden, die Bestandteil von Systemd sind.
Poettering ist ein junger, recht gesprächiger Entwickler, der in Berlin wohnt und für Red Hat arbeitet. Mit seinen Ideen, zuerst PulseAudio, jetzt systemd, hat er schon einiges bewegt und kann sicherlich noch weiteres bewegen. Nach PulseAudio befragt, sagte er, dass die meisten noch verbleibenden Probleme von Treibern stammen, die falsche Timing-Informationen liefern. Diese führen dazu, dass PulseAudio seine Ausgaben falsch berechnet. Sogar der Treiber der Audio-Karte in seinem Laptop gehört noch zu diesen Übeltätern. Im Rückblick meint Poettering, mit PulseAudio nichts falsch gemacht zu haben. Man hätte es nicht anders einführen können, als es tatsächlich geschah. Wenn es aus Sicht der Benutzer zu lange dauerte, die Fehler zu beheben, liege das daran, dass weltweit gerade einmal zwei oder drei Entwickler für die Arbeit am Linux-Audiosystem bezahlt werden. Die Arbeit geht zwar weiter, aber schneller war es eben nicht möglich.
Tobias Jähnel stellte OFS, ein Offline-Dateisystem auf Basis von FUSE (PDF-Datei), vor. Dieses Dateisystem könnte für alle interessant werden, die auf Netzlaufwerke zugreifen, aber nicht ständig mit diesen verbunden sind. OFS soll für die automatische Erkennung des Verbindungszustands, Cachen von lokalen Änderungen bei Trennung vom Netz und automatische Synchronisation bei erneuter Verbindung sorgen. Da das Dateisystem eine starke Interaktion mit dem Benutzer benötigt, sind Kommandozeilen- sowie GUI-Tools vorgesehen.
x86-Experte Andi Kleen stellte in »mcelog: Memory error handling in user space« (PDF-Datei) die neue Generation des Tools mcelog vor, die wesentlich mehr zu bieten hat als die bisherige Version. Sie soll alle Fehler, die in ECC-RAM auftreten, zählen und entsprechende Warnungen und Statistiken ausgeben können. Die neuesten Intel-Prozessoren bieten auch Zähler für Cache-Fehler an, sicher eine längst überfällige Maßnahme, wenn man bedenkt, dass Caches den größten Teil der Chipfläche einnehmen. Udo Seidel referierte in »Divide and conquer: Shared disk cluster file systems shipped with Linux« (PDF-Datei) über die Cluster-Dateisysteme GFS und OCFS2 und verglich ihre Features und ihre Verwaltungsmöglichkeiten.
Nach einer letzten, dringend benötigten Kaffeepause standen nochmals vier Vorträge auf dem Plan. Stefan Seyfried stellte in »Resource Management in Linux with Control Groups (cgroups)« (PDF-Datei) die Möglichkeiten des Control Group-Subsystems vor. Systemadministratoren, die diese recht junge Funktionalität noch nicht kennen, sollten sie sich baldigst aneignen. Daher wird ein Artikel von Stefan Seyfried und seinem Kollegen zu cgroups demnächst auf Pro-Linux erscheinen. Die Fortsetzung dieses Vortrags war »The userspace solution for control groups« von Dhaval Giani (PDF-Datei). Der Referent ging in diesem Vortrag in die Details der Bibliothek libcgroup, die im anstehenden Artikel auch Erwähnung finden wird, inzwischen aber schon etwas fortgeschritten ist.
»Porting of IPv4 Applications to IPv4/IPv6 dual-stack« (PDF-Datei) war das Thema von Owen DeLong. Es war ein praktischer Vortrag für Entwickler, die sich die Grundlagen der IPv6-Programmierung in C, Perl und Python aneignen wollten, und die Kurzfassung des Mittwochs-Tutorials zum gleichen Thema. Rainer Gerhards schließlich, der Autor von rsyslog, analysierte in »rsyslog: going up from 40K messages per second to 250K« (PDF-Datei) die Optimierung von rsyslog durch Parallelisierung und andere Maßnahmen.
Die Ausarbeitung der eingereichten Beiträge, soweit sie von den Referenten rechtzeitig eingereicht wurden, sind in einem Konferenzband zusammengefasst. Interessenten können diesen Band unter der ISBN 978-3-86541-398-7 bestellen.
Fazit
Der Linux-Kongress bot wieder ein sehr gutes Programm und war wie gewohnt gut organisiert. Bei einzelnen Vorträgen war die eingereichte Ausarbeitung besser als der Vortrag, aber eigentlich brachten alle Referenten ihr Thema gut an die Zuhörerschaft. Einige müssen allerdings kritisiert werden, weil sie weder rechtzeitig ihre Ausarbeitung eingereicht noch (bisher) ihre Unterlagen bereitgestellt haben.
Die Themen der Vorträge trafen genau die derzeit aktuellsten und wichtigsten Entwicklungen im Linux-Umfeld. Leistungsmessung und Tracing, Virtualisierung, Netzwerkprotokolle und Dateisysteme führten klar die Liste an. Die wenigen sonstigen Vorträge passten durchweg in den Themenkomplex »Systemverwaltung«.
Natürlich kann man den Linux-Kongress nicht als Kongress im üblichen Sinne bezeichnen, da er auch von der Größe her mehr eine Fachtagung darstellt. Leider wird der Kongress jedes Jahr kleiner. Der Hauptgrund dürfte recht sicher in der ständig steigenden Zahl von konkurrierenden Kongressen zu suchen sein. Außerdem ist der Themenbereich des Linux-Kongresses doch recht speziell, und somit bleibt die Zielgruppe begrenzt. Wenn weiterhin jedes Jahr zehn Teilnehmer weniger kommen, wird es nicht mehr lange dauern, bis der Kongress eingestellt werden muss. Es wäre sehr schade um diese traditionsreiche Veranstaltung.



