Software::Kernel
Linux 4.20 auf Kurs für Weihnachten, ext4-Problem noch ungelöst
In der am Wochenende veröffentlichten fünften Testversion von Linux 4.20 wurde das durch den STIBP-Patch verursachte Geschwindigkeitsproblem behoben. Linux 4.20 wird daher sehr wahrscheinlich am 23. Dezember erscheinen. Die Suche nach der Dateisystemkorruption in ext4 hat dagegen bisher noch kein endgültiges Ergebnis geliefert.
Larry Ewing
Die
erste Vorschau auf Linux 4.20 brachte vor vier Wochen weitere Maßnahmen gegen
neue Varianten des katastrophalen Prozessorfehlers Spectre. Dabei wurde auch die STIBP-Funktionalität integriert, die bei Prozessoren mit aktiviertem Hyperthreading davor schützt, dass Prozesse, die im selben Prozessorkern laufen, Informationen des anderen Prozesses auslesen können. Durch Benchmarks von Phoronix
fiel kurz danach auf, dass die Geschwindigkeit von Linux 4.20 massiv beeinträchtigt war. Ein
Patch von Thomas Gleixner behob vor einer Woche das Problem, jetzt wurde er von Linus Torvalds in
Linux 4.20-rc5 übernommen. Anlässlich dieser Testversion stellte Torvalds fest, dass die Entwicklung von Linux 4.20 abgesehen von STIBP normal verlaufe und somit wohl nichts gegen die Veröffentlichung am Sonntag, dem 23. Dezember, spreche. Dieser Termin ist allerdings nicht besonders günstig, da damit die erste Woche der zweiwöchigen Integrationsphase für die nächste Version auf die Feiertage fällt, an denen auch Torvalds keinen Stress wünscht. Würde er andererseits den Termin verschieben, müssten die Entwickler ihre Patches für die nächste Version in der Weihnachtswoche vorbereiten, was auch nicht wünschenswert ist. Das bedeutet, dass es wohl beim 23. Dezember bleibt und Linux 4.20 somit direkt unter den Weihnachtsbaum gelegt werden kann.
Weiterhin mysteriös bleibt die Dateisystemkorruption in ext4, die von einigen Anwendern in Linux 4.19 berichtet wurde. Die Suche wird dadurch erschwert, dass bisher weder Theodore Ts'o, der Hauptentwickler von ext4, noch Jens Axboe, Betreuer des Block-Subsystems, auf ihren Systemen das Problem reproduzieren konnten. Sie sind daher auf Berichte der Anwender angewiesen, und diese geben noch kein klares Bild. So gibt es inzwischen Angaben, nach denen in Linux 4.19.6 das Problem nicht mehr auftrat, während es in 4.19.0 definitiv vorhanden war. Es wurden auch Patches identifiziert, die für diese Verbesserung verantwortlich sein dürften, da sie Fehler in den relevanten Bereichen korrigieren. Theodore Ts'o versuchte die vorliegenden Berichte zu sortieren und ist der Meinung, dass die durchaus ähnlichen Symptome zwei oder sogar drei unterschiedliche Ursachen haben könnten. So kann eine Unterbrechung der Verbindung zu einem USB-Gerät zu ähnlichen Meldungen führen.
Auf virtuellen Maschinen scheint das Problem überhaupt nicht aufzutreten. Eine weitere Beobachtung von Ts'o ist, dass die Probleme oft nach intensivem Lesen vom Dateisystem auftreten, nicht beim Schreiben. Das führte ihn zu der Vermutung, dass möglicherweise falsche Daten im Cache des Kernels stehen. Vereinzelte Berichte, die von Korruption auch mit Btrfs und ZFS berichten, könnten in dieselbe Richtung deuten.
Zudem gibt es auch einen Hinweis, dass ein Compilerfehler der Auslöser des Problems sein könnte. Dies scheint sich jedoch nicht zu bestätigen. Somit konzentriert sich die Suche zunächst darauf, reproduzierbare Bedingungen anzugeben, und nach der exakten Kernel-Änderung zu suchen, ab der das Problem auftritt. Neue Erkenntnisse werden ständig dem Eintrag im Kernel-Bugzilla hinzugefügt. Die Lösung wird mit Sicherheit gefunden werden, aber wie lange es noch dauern wird, ist ungewiss.
){kind=small}
