# ext3 zerschossen, aber wie?

## sprittwicht

Mein ext3-Dateisystem meldete nach dem heutigen Booten erstmals diverse Fehler in /var/log/messages:

Ca. 30 Mal:

EXT3-fs error (device sda3): ext3_lookup: deleted inode referenced: 21856417

Außerdem mehrere davon:

EXT3-fs error (device sda3): ext3_valid_block_bitmap: Invalid block bitmap - block_group = 2622, block = 85917697

EXT3-fs error (device sda3): ext3_new_block: Allocating block in system zone - blocks from 85917697, length 1

e2fsck spuckte schließlich so viele Fehler aus, dass ich die manuelle Korrektur abgebrochen und e2fsck -y ausgeführt habe, also alle Fehler automatisch korrigiert.

Im Verlauf zeigte er dann zum Schluss Dutzende (Hunderte?) Dateien, die sich Blocks mit anderen teilten.

Einige von denen sind jetzt tatsächlich kaputt.

Die große Preisfrage lautet jetzt: Was ist passiert?

Der Rechner wurde immer sauber runtergefahren, die Platte meldet keine Smart-Fehler.

Die letzte Aktion gestern war ein größeres Update, anschließendes Suspend to Disk per hibernate-Script (tuxonice-sources).

Das Aufwachen hat auch noch geklappt, der komplette Neustart danach nicht mehr (Einloggen in KDE nicht möglich).

Beim darauffolgenden Neustart war dann e2fsck angesagt, mit besagtem Resultat. :-/

----------

## haegar87

Servus,

ist jetzt nur ein Schuss ins Blaue, aber war bei dem größeren Update zufällig auch ein Kernel-Update dabei (mit neu gebautem Kernel)?

Wurde dort vielleicht die ext4 Unterstützung ohne die Subpunkte ext2/ext3 Unterstützung eingebaut?

Hab irgendwo (die Quelle müsste ich erst suchen) davon gelesen, dass der ext4 "Treiber" dann manchmal seltsamerweise trotzdem ext3 mountet, aber als 4er behandelt, was zu allerlei merkwürdigen Fehlern im Dateisystem führt, ohne erkennbare Ursache.

Aber wie gesagt, dass ist nur ein reiner Schuss ins Blaue. Ansonsten steht noch irgentwas interessantes zur sda in den logs (BUS ERROR ; REMAPPING ; I/O ERROR etc.)?

Vielleicht hat die Platte ja einen Kabelschaden (SATA-Kabel)... dann würde SMART (da direkt von der Firmware der Platte gesteuert) keine Fehler ausgeben, das System kann trotzdem nicht sauber auf die Platte zugreifen.

Da könnte man noch einen SMART Test mit der Option "-C" einen Test im "captive mode" durchführen, da haben sich bei mir defekte SATA Kabel immer bemerkbar gemacht.

MfG

haegar87

----------

## Klaus Meier

Ich würde mir schleunigst ein sicheres Plätzchen für wichtige Daten suchen. Meine Erfahrung mit defekten Platten: Es tritt so etwas auf, was du hast. Dann biegt man es hin und ist erst mal glücklich, dass es wieder geht. Und nach einer Woche tritt genau das gleiche Problem wieder auf. Und irgendwann sind dann wirklich wichtige Sache weg.

Es kann schon sein, dass es sich bei dir um einen Crash vom Filesystem handelt oder beim Kernel etwas schief gegangen ist. Aber die Tatsache, dass es erst mal wieder geht, ist kein Hinweis darauf, dass die Platte in Ordnung ist. Wenn alle Daten gesichert sind, kannst du das alles viel entspannter beobachten.

----------

## sprittwicht

Ist Gott sei Dank nichts Wichtiges drauf, bzw. nur Sachen, die eh noch auf anderen Rechnern und/oder externen Platten liegen.

Die Installation ist nicht mehr zu gebrauchen, es wurden wahllos Systemdateien gelöscht.

Total geil gerade: less /var/log/messages-irgendwas.gz zeigt mir den Inhalt korrekt an, das gleiche mit "| grep sda3" dahinter spuckt die Fehlerzeilen aus der aktuellen /var/log/messages aus (inklusive aktuellem Datum, die Einträge sind so in der archivierten .gz definitiv nicht vorhanden).

Alles total im Eimer hier.

Werde mal den Smart-Test laufen lassen und memtest86, vielleicht ist dem Kollegen etwas warm geworden.  :Smile: 

Meine Hauptsorge ist aber dass ich irgendwie zu doof für ext3 bin, auf einem anderen Rechner (gentoo-sources, keine suspend-Zaubereien) hatte ich auch schon mehrmals beim Runterfahren Kernel-OOPSe mit Hinweisen auf bestimmte ext3-Quellcodedateien. In beiden Rechnern werkeln auch keine bösen Nvidia-Binary-Treiber, Speichertests (schon etwas länger her) waren immer gut, so dass mein Vertrauen in den Linux-Kernel, respektive ext3, gerade ein bisschen... schwindet. :-/

Beim letzten Update wurde der Kernel nicht ausgetauscht, ext3-Unterstützung ist auch ganz normal drin.

Danke euch erstmal für die Tips, zumindest wird mir jetzt über Rest-Pfingsten nicht langweilig.  :Smile: 

----------

## Klaus Meier

Also, um ext3 nutzen zu können, muss man keine besondere Intelligenz mitbringen. Und es ist ja nun schon uralt und gut durchgetestet, ohne dass da irgend etwas aufgefallen ist. Wackelkontakt beim Kabel klingt auch nicht schlecht. Dann wird dir Smart absolut nichts anzeigen. Falls du noch ein anderes rumfliegen hast, probiere es mal aus.Oder das Kabel ein paarmal ab- und wieder anstecken.

----------

## sprittwicht

OK, der falsche Dateiinhalt von /var/log/messages-xyz.gz war Quatsch, hatte mich bei dem Kommando verbaselt.  :Smile: 

Memtest (zwar kurz) war unauffällig, Kabel hab ich mehrmals umgesteckt, ausgetauscht, andere Laufwerke abgeklemmt: Die "captive"-Tests von smartctl (unter Knoppix) brechen immer ab ("Interrupted (host reset)      90%").

Der nicht-captive Short-Test läuft dagegen fehlerfrei, Long hab ich noch nicht probiert.

----------

## sprittwicht

Hat das hibernate-Script irgendwas mit upower zu schaffen? Das hatte ich im Zuge der Updates nämlich deinstalliert.

Ist aber meine ich unabhängig von upower, und läuft ja jetzt auch ohne...

----------

## Klaus Meier

Es sollte kein Plattenproblem geben, wenn du das Hibernate Scriipt deinstallierst. Eigentlich nur, wenn du so etwas falsch nutzt. Also als Ziel für Suspend eine Datenpartition angibst. Wenn du das Kabel gewechselt hast, dann solltest du es damit aber schon etwas testen, ob das Problem erneut auftritt. Das Smart abbricht deutet aber auf einen Plattendefekt hin. Wie alt ist die Platte? Noch Garantie?

----------

## haegar87

Okay, jetzt bin ich verwirrt...

 *Quote:*   

> ("Interrupted (host reset) 90%")

 

Deutet darauf hin, dass nicht die Platte sondern der Host/Controller den Test abgebrochen hat.

Deshalb läuft der nicht captive Test auch durch, dort wird der Firmware der Platte nur gesagt: "Mach mal SMART und sag mir das Ergebnis" während der captive Test aktiv durch den Host/Controller durchgeführt wird.

Also ich hätte jetzt auf das SATA Kabel getippt, aber wenn du das schon getauscht hast weiß ich gerade auch nicht weiter.

----------

## sprittwicht

So, inzwischen eine zweite Platte drangehängt: Alle Daten erfolgreich rüberkopiert, im Syslog weder Fehler mit der neuen noch der alten Platte.

Der Captive-Test bricht allerdings auch bei der Ersatzplatte mit dem gleichen Ergebnis ab.   :Shocked: 

Hat das Mainboard einen Hau weg?

----------

## Klaus Meier

Du hast ja auf dem Mainboard im Normalfall 2 Controller. Also erst mal den vom Chipsatz und dann meistens noch einen aufgelöteten. Hänge die Platte doch mal an den anderen Controller. Und wenn es geht, teste die Platten auch mal an einem anderen Computer. Dann lässt sich diese Frage beantworten.

----------

## sprittwicht

Mittlerweile alles neu installiert, mal schauen ob's läuft.

Den Captive-Tests der smartmontools traue ich keinen Meter: Die liefen bis jetzt nur in einem anderen Rechner, und dort auch nur mit ner neuen SSD. Hänge ich an den gleichen Controller eine etwas ältere, "normale" Festplatte, knallt der gleiche Test wieder mit der "Interrupted: Host reset"-Meldung.

Denke mal dass einfach das Sata-Kabel wackelig war (den Erfinder dieses Steckerdesigns sollte man übrigens erschießen) und in der Folge der Tuxonice-Patch Chaos und Schrecken im Dateisystem verbreitet hat.

Sicherheitshalber verkneif ich mir den Tuxonice jetzt komplett, die 5 Sekunden mehr beim Booten werde ich gerade noch so verkraften.  :Smile: 

----------

## Klaus Meier

Nun tu mal dem Tuxonice nicht Unrecht. Was kann der denn dafür, wenn da ein Kabel wackelig ist...

Aber das mit dem Kabel klingt wirklich am logischsten. Tja, es muss heute halt alles klein und leicht sein. Funktionalität interessiert da eher nicht.

----------

