Login
Newsletter
Werbung

Do, 6. Dezember 2018, 14:50

Software::Kernel

Dateisystemkorruption in Linux 4.19 behoben

Die von einigen Benutzern gemeldete Dateisystemkorruption, die auftrat, nachdem sie auf Linux 4.19 aktualisiert hatten, konnte jetzt behoben werden. Anders als zuerst vermutet lag das Problem nicht im Dateisystem ext4, sondern in der Block-Schicht, die zwischen Dateisystemen und Gerätetreibern liegt.

Larry Ewing

Die gemeinsame Anstrengung etlicher Benutzer und Entwickler machte es möglich, dass das Problem, das sich als Dateisystemkorruption bemerkbar machte, jetzt schneller als erwartet identifiziert und behoben werden konnte. Erste Berichte auf der Kernel-Mailingliste und an anderen Stellen zeigten seit Ende November auf, dass einige Benutzer ein korruptes Dateisystem erhielten, nachdem sie auf Linux 4.19 aktualisiert hatten. Ein Dateisystem-Check und Rückkehr zu Linux 4.18 behob für alle Betroffenen das Problem. Damit war bereits klar, dass das Problem auf dem Weg zu Linux 4.19 entstanden sein musste.

Die Suche nach der Ursache war nicht leicht, da es zunächst an Informationen fehlte, das Problem nachzuvollziehen. Diese Informationen zu ermitteln, ist der Beharrlichkeit von Guenter Roeck zu verdanken, der das Problem als erster meldete. Letztlich war es Lukáš Krejčí, der eine Methode angab, das Problem binnen Minuten zu reproduzieren, ein Skript dafür bereitstellte, und auch die entscheidende Änderung im Kernel identifizierte, mit der das Problem begann.

Jens Axboe, der vielbeschäftigte Hauptbetreuer des Block-Subsystems und der ATA- und SATA-Treiber, konnte schnell eine Erklärung für das Problem finden. Eine Schreiboperation wird normalerweise in eine Warteschlange des I/O-Schedulers eingereiht. Durch die in Linux 4.19-rc1 eingeführte Optimierung wurde versucht, die Warteschlange zu umgehen, wenn der Treiber unbeschäftigt ist. Wenn das scheitert, wird die Operation doch in die Warteschlange eingefügt. Doch dann hat die SCSI-Schicht bereits Scatter-Gather-Tabellen für das Kommando angelegt, während gleichzeitig in der Block-Schicht die Operation mit neuen Operationen vereinigt werden kann, wenn schnell weitere Operationen eintreffen. Dies resultierte im Schreiben von unsinnigen Daten auf die Festplatte.

Im Nachhinein betrachtet ist klar, dass das Problem alle Dateisysteme in Linux 4.19-rc1 bis zur aktuellen Testversion von Linux 4.20 betreffen konnte. Dies erklärt auch vereinzelte Meldungen mit Btrfs, XFS und auch ZFS. Weil unterschiedliche Dateisysteme unterschiedlich anfällig sein könnten und unterschiedlich stark verbreitet sind, wurden die meisten Beobachtungen mit ext4 gemacht. Der Fehler konnte auch nur unter hoher Last auftreten und auch nicht mit allen Geräten, was erklärt, dass viele Benutzer offenbar nicht betroffen waren.

Der mittlerweile epische Kernel-Bugzilla-Eintrag enthält alle Details zu dem Problem. So stellte sich auch Axboe die naheliegende Frage, warum das Problem von den automatischen Tests nicht gefunden wurde. Immerhin betreiben diverse Initiativen und Linux-Distributoren umfangreiche Serverfarmen, die kontinuierlich mehr oder minder intensive Tests ausführen. Laut Axboe sind die Bedingungen, dass der Treiber die neuere Multiqueue-Implementation nutzt, keinen I/O-Scheduler nutzt, die Ein/Ausgabelast so hoch sein muss, dass der Treiber voll ausgelastet ist, und der Treiber interne Zustände über mehrere Warteschlange-Einreihungen hinweg speichert. Aus diesem Grund waren NVME-Geräte nicht betroffen, SCSI nur sehr selten, da »99,99% von SCSI« kein Multiqueue verwenden. Diese Lücken in den automatisierten Tests sollen geschlossen werden, außerdem will Axboe einen Regressionstest für diesen Fall hinzufügen.

Die Korrektur des Problems, anfänglich nur ein Einzeiler, ist nun auf dem Weg in den offiziellen Kernel. Axboe verzichtete wegen der Dringlichkeit des Problems auf Experimente und hielt die Änderungen so klein wie möglich. Der gesamte Bereich müsse aber seiner Ansicht nach mal wieder aufgeräumt werden, wonach dann noch weiter optimiert werden kann. Die Arbeiten daran laufen bereits.

Auch wenn es unglücklich ist, dass gerade jetzt ein schwerwiegender Fehler in der Multiqueue-Implementation gefunden wurde, hält Axboe an dem Plan fest, die Singlequeue-Implementation in Linux 4.21 (oder 5.0) ganz zu entfernen. Die meisten Treiber sind ohnehin bereits umgestellt. Der Fehler in der Multiqueue-Implementation war laut Axboe der schwerwiegendste »seit Dekaden« und sei nur ein Grund mehr, die alte Implementation loszuwerden. Denn die neue Implementation sei ja die besser gewartete und abgesehen von diesem einen Fehler auch sehr zuverlässig. Guenter Roeck sprach sich zwar dagegen aus, die alte Implementation so bald zu entfernen, aber Axboe als Verantwortlicher wird sich wohl durchsetzen.

Werbung
Kommentare (Insgesamt: 19 || Alle anzeigen )
Schön das er behoben ist (schmidicom, Mo, 10. Dezember 2018)
Re: Dateisystemkorruption in Linux 4.19 behoben - ab 4.19.8 (schmidicom, Mo, 10. Dezember 2018)
Re: Dateisystemkorruption in Linux 4.19 behoben - ab 4.19.8 (Verfluchtnochmal_5987109, Sa, 8. Dezember 2018)
Re: Der "Pole" (oder Tscheche...) (blablabla233, Fr, 7. Dezember 2018)
Re[4]: Der Wahnsinn hat System (Blablabla233, Fr, 7. Dezember 2018)
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung