Re: EXT3-fs error (device hdb5) in start_transaction: Journal has aborted
Gruesse!
* Thorsten Steinbrenner <news@billroth.de> schrieb am [09.07.06 14:42]:
> Thorsten Steinbrenner schrieb:
>
> >EXT3-fs error (device hdb5) in start_transaction: Journal has aborted
>
> Hm, keiner mehr eine Idee?! Schade. Weiß nämlich nicht wo ich weiter suchen soll. Und der Server
> bleibt halt einfach stehen - das ist ein kleines Desaster...
Ideen schon ;-)
Kurzes Googlen zeigt, daß diese Meldung schon ein paar Jahre "auftritt".
Nichts deutet beim Querlesen auf einen Kernel/FS-Bug hin, eher laufen
die Vermutungen in Richtung Hardware.
Versuche doch mal zum auftretenden Fehler Gemeinsamkeiten zu finden,
z.B.:
- tritt der Fehler zu einer bestimmten Uhrzeit/Tageszeit auf (beliebt
sind die morgendlichen Cron-Läufe ca. 06:30)?
- Installiere dir z.B. munin und schaue, ob zum Fehlerzeitpunkt
Auffälligkeiten bei Load, CPU-Last, Bus/HD-IO, Sensors besteht
- Intensiviere evtl. den Debug-Level für Kernel bzw. FS. Kann dir aber
leider nicht sagen, ob du dafür einen eigenen, angepaßten Kernel
brauchst (evtl. weiß das jemand anderes)
- Deine Tests mit der Platte (badblock) war ja sicher immer nur ein Lese
bzw. nicht-destruktiver Scanlauf. Hast du die Möglichkeit, die Platte
auch destruktiv, also mit wirklichem (Über)schreiben der daten zu
testen? Bzw. einfach eine andere Platte du nehmen? Auch Kabel, Netzteil,
RAM können da eine Rolle spielen.
- Wie ist der SMART-Status der Platte? Gibt es Fehler z.B. bei einem
long selftest? Was sagt das Testprogramm des Herstellers (Drive Fitness
Tests)? Wenn nicht sowieso schon geschehen: lass den smartd mitlaufen,
ob sich vor Auftreten des Fehlers ein Smart-Wert ändert.
Du wirst sehen, ohne systematische Analyse wirst du da nicht
weiterkommen.
> Viele Grüße,
>
>
> Tom
Gruß
Gerhard
--
Kernel panic: Could not determine whether
bit was one, zero or sqrt(1/PI)...
(J.K. in d-u-g)
Reply to: