News Fehler in aktuellen Linux-Kerneln

[blöderidiot]

Das ist gar nicht so schwer aus Versehen hinzubekommen. Der Fehler ist also ziemlich ernst meine ich. Zum Glück (in diesem Fall) nutzen nicht so viele wirklich topaktuelle Kernel. Der Bug ist erst seit 3.6.2 drin, was am 12. Oktober released wurde.

Der Fehler ist auch im aktuellen SuSE 12.2-Update-Kernel drin (3.4.x). Hat aber irgendwie (bei mir jedenfalls) mit aktiviertem NFS4 zu tun. Kann auch Zufall oder eben ein Trigger sein. Da ich heute einige Clusterknoten installieren wollte und erst auf "Hardware" tippte, atme ich diesbezüglich zwar auf - ärgere mich aber wegen der vergeudeten Zeit (das passiert genau dann, wenn das sauber eingerichtete System bei aktiviertem NFS4 neu gebootet wird z.B. wegen Kernel-Update oder weil man es in den Schrank stellt). Habe heute 2 x deswegen ein Grundsystem neu aufgesetzt (und geflucht).

Und wenn das nicht ernst ist, weiß ich auch nicht was ernst sein soll.

 

[fethomm]

Hat aber irgendwie (bei mir jedenfalls) mit aktiviertem NFS4 zu tun.

Die Mailingliste zu Linux-NFS hat auch entsprechende Beiträge

 

[blöderidiot]

Ich nutze im Moment einen 3.4 Kernel aber der Bug ist bei mir nicht drin.

Laut https://lwn.net/Articles/521022/ sind

• 3.4.14
• 3.4.15
• 3.5.7
• 3.6.2
• 3.6.3

betroffen. Freu Dich (und reboote) nicht zu früh!

 

[Eisenfaust]

Man kann das Problem auch dadurch umgehen, indem man einfach ein echtes UNIX Betriebssystem benutzt.

Fehler schleichen sich immer mal welche ein. Bei Frickelsystemen statistisch häufiger als bei anderen, konservativ entwickelten Betriebssystemen. Peinlich ist nach meiner Meinung, daß dieser Bug die absurd kurzen und der Komplexitat des Systems kaum angemessenen Veröffentlichungs- und Stabildeklarationszyklen offenlegt.

 

[mensch183]

Man kann das Problem auch dadurch umgehen, indem man einfach ein echtes UNIX Betriebssystem benutzt.

Fehler schleichen sich immer mal welche ein. Bei Frickelsystemen statistisch häufiger als bei anderen, konservativ entwickelten Betriebssystemen

Das fett markierte ist Neusprech für nahezu tote Pferde. Die von dir "entdeckte" statistische Gesetzmäßigkeit beschreibt man allgemein so: "Wer nichts macht, macht auch nichts falsch."

Achja:
Gut, dass die Ursache wohl doch eine andere ist, als anfangs gedacht.

 

[Nugget100]

Das Lustige ist das viele Ahnungslos einfach Ext 4 verwenden. Dabei tuts in 99% aller Fälle immer noch das Ext 3. Bei den Kunden die bei mir (Geschäftlich IT Umfeld) betroffen sind, werden die Partitionen auf denen die Datne sind Kopiert, gelöscht und formatiert ,dann die Daten zurückgespielt. Beim / Verzeichnis nur die Kundendaten ( /home) gesichert Kiste Plattgemacht und auf Ext 3 umgestellt. Als Ext 4 herauskam war ich schon skeptisch ob das funzt ,andererseits war es notwendig ein Dateisystem zu haben das Kapazitäten größer 4 TB verwalten kann. Generell kann man alles unter 4 TB getroßt mit Ext 3 verwenden. Ext 3 ist ja letztendlich nichts anderes als ein Ext 2 mit Journalfunktion.

 

[westef]

Weiß gar nicht, was du mit deinem ext3 immer hast. ext3 ist halt obsolet und ext4 der Nachfolger. In ext3 kann auch noch ein Bug drin sein. Die ursprüngliche Analyse von Ted Tso hat sich übrigens als falsch herausgestellt (das mit den schnellen Reboots). Das genaue Problem kennen sie noch nicht.

Achja, aus einer Mail von Ted Tso:

That's not to say we aren't treating this seriously; but people
shouldn't panic unduly.... (and if you are using a critical
enterprise/production server on bleeding edge kernels, may I suggest
that this might not be such a good idea; there is a *reason* why
enterprise Linux distro's spend 6-9 months or more just stablizing the
kernel, and being super paranoid about making changes afterwards for
years, and it's not because they enjoy backporting patches and working
with trailing edge kernel sources. :-)

Und da verstehe ich dich nicht Nugget100. Wenn du Geschäftskunden betreust, die wichtige Daten auf ihren servern haben, warum installierst du denen dann bleeding edge Kernel und keine "stabilen" Kernel, auf denen Debian oder Red Hat basiert?

 

[fethomm]

Artikel-Update: Nach weiteren Untersuchungen hat Ted Ts'o festgestellt, dass der Bug, der potenziell Daten im EXT4-Dateisystem zerstört, nicht die zuerst angenommene Ursache hat und somit seine erste Analyse falsch war. Der Fehler kann, so der jetzige Stand der Dinge, nur bei einem unsauberen Herunterfahren des Systems oder einem umount mit den Parametern -l und nobarrier eintreten. Letzteres ist eine sehr ungewöhnliche Kombination und muss händisch eingegeben werden. Weitere Fehlermeldungen von Betroffenen sind bisher nicht bekannt. Dies wäre aber zu erwarten, da Distributionen wie Fedora 17 oder Siduction die Kernel 3.6.2 und 3.6.3 bereits seit deren Erscheinen nutzen. Ts'o sagt, dies sei keine Entwarnung, es stelle den Fehler lediglich in ein anderes Licht. Hier zeigt sich wieder einmal einer der großen Vorteile quelloffener Software-Entwicklung: Bugs werden offen diskutiert und zeitnah behoben, renommierte Entwickler wie Ts'o scheuen sich nicht, Fehler öffentlich einzugestehen. Nichts wird vertuscht.

 

[Flachzange]

Tippfehler im Update:

Kernerl 3.6.2 und 3.6.3

 

[Heretic Novalis]

Immer wieder interessant:
Linux-Derivate weisen (teils kritische) Fehler auf: "kein Problem", "geht schon", "wird schon", "passiert halt"
Windows weist (egal ob kleinere oder größere) Fehler auf: "M$ kann nix", "mit Linux wär das nicht passiert", "war doch klar", "ist immer so", "Windoof halt"

...sehr schön zu sehen an Beitrag #25

-.-

@Update
Wie lange braucht man, um ein bekanntes Problem bzgl. Dateivernichtung zu isolieren und zu eliminieren? Tage? Wochen? Monate? Irgendwie zieht sich da ein roter Faden durch "alternative" bzw. "freie" Programme - egal ob Mozilla, Java (gibts da eigentlich mittlerweile was Neues?) oder Linux und dessen Distributionen. Und bei dem organisationsfreien Kram hat man nichtmal Regressansprüche... "Nutzung auf eigene Gefahr".

Gerade dieser Fehler ist für dieses OS sehr wohl bedeutsam. Wenn ich mein System als Fileserver aufsetze und - aus welchen Gründen auch immer - der Rechner "unkontrolliert" abschaltet, hab ich halt Pech gehabt? Das kanns nicht sein, ist aber wohl auch kein Problem für die "Pros". Nur der "Normaluser" hat das Nachsehen...

 

[KillX]

...da Distributionen wie Fedora 7...

Ich glaube das sollte Fedora 17 heißen =)

@Heretic Novalis

Hast dir den Fehler überhaupt mal durchgelesen? Wird die wenigsten betreffen. Schon alleine weil die meisten die betroffenen Kernel noch überhaupt nicht benutzen. Und im Gegensatz zu proprietärer Software, werden solche Bugs/Fehler nicht erst vertuscht und in der Regel schneller gefixt.

 

[EiRoGGe]

...da Distributionen wie Fedora 7...

Ich glaube das sollte Fedora 17 heißen =)

Und Kernel 3.6.2/3.6.3 statt 2.6.2/2.6.3.

 

[NemesisFS]

@Heretic Novalis:
Auf einem Fileserver verwendet man keine frischen Kernel, aus eben genannten Gründen.

Außerdem spricht es eher für Linux, das, obwohl man keine Ansprüche auf Schadensersatz hat 90% aller Server damit laufen.

 

[GlockMane88]

Warum portiert man den Fehler zurück auf ältere Kernel? Hat man den kurzerhand zum Feature erklärt (Apple Style ) oder was?

 

[Fonce]

Weil sich Fehler nun mal einschleichen können in neuen Code und erst dann auffallen nachdem die Rückportierung erfolgt ist?

 

[baizon]

Also den Fehler zu erhalten ist wirklich eine Kunst, oder wer mach so was im Alltag...

Das Problem war bei einem User aufgetreten, der in einem komplexen Setup lokale und NFS-Laufwerke ineinander mountet und die Dateisysteme beim Herunterfahren mit der umount-Option "-l" (lazy unmount) aushängt. Dabei werden die Laufwerke sofort ausgehängt, auch wenn sie noch beschäftigt sind (umount-Fehlermeldung ohne "-l": "device busy"), weil noch auf Dateien oder Verzeichnisse zugegriffen wird oder der NFS-Server hängt. Wird der Rechner vor dem Abschluss der nach einem "lazy unmount" nötigen Aufräumarbeiten heruntergefahren, kann das beobachtete Verhalten vorkommen, wenn zudem spezielle Mount-Optionen (unter Verdacht stehen nobarrier und journal_async_commit) verwendet werden.

Quelle: http://www.heise.de/open/meldung/Ext4-Bug-Entwarnung-1736902.html

 

[blöderidiot]

Also den Fehler zu erhalten ist wirklich eine Kunst, oder wer mach so was im Alltag...

Ich halte diese "Entwarnungen" für Humbug. Wenn ich als kleiner Anwender diesen Bug gestern tagsüber zweimal hintereinander reproduzierbar triggern konnte, dann steckt da mehr dahinter (imho).

1. neues System aufspielen (Suse 12.2 Basis + Textmode)
2. reboot
3. Kernelupdate (default 3.14.buggy)
4. reboot
5. NFS einrichten
6. ein paar Testprogramme über NFS4-Share starten
7. alles o.k.? - shutdown

kernel oops + booooom beim Hochfahren

my €0.02

 

[mensch183]

7. alles o.k.? - shutdown

kernel oops + booooom beim Hochfahren

Wie kommst du auf die Idee, dass der in dem Thread thematisierte Bug irgendwas damit zu tun hat? Es geht "nur" um kaputte Filesysteme.

 

[baizon]

Ich halte diese "Entwarnungen" für Humbug. Wenn ich als kleiner Anwender diesen Bug gestern tagsüber zweimal hintereinander reproduzierbar triggern konnte, dann steckt da mehr dahinter (imho).

Man beachte, es muss "lazy unmount" genutzt werden. Wenn jemand so einen Befehl nutzt, sollte sich nicht wundern.

 

[Fonce]

Vorallem dürfte wohl niemand auf die Idee kommen lazy unmount bei kritische Daten zu nutzen, den hier werden im Cache befibdliche Scheiboperationen einfach verworfen was schon zu Datenverlust führen kann.