Panic nach Crash

[pertze]

Hallo,

nach einem Crash haben wir Probleme mit unserem FreeBSD-6.1-RELEASE Server. Er fährt normal hoch, das Raid 1 ist auch ok. Aber nach ca. 1 Minute uptime kommt folgender Fehler:

panic: lockmgr: locking against myself
Uptime: 1m12s
Cannot dump. No dump device defined.
Automatic reboot in 15 seconds - press a key on the console to abort

Abbrechen kann ich den Reboot nicht, selbst wenn ich eine Taste drücke. Er will natürlich einen bg_fsck machen, da die Filesysteme nicht ordnungsgemäß dismounted wurden. Aber da er schon nach 1 Min rebootet wird das nix. Ich habe dann im Singleuser Mode ein fsck gemacht (btw, im Singleuser Mode rebootet er nicht einfach so). Er hatte nur eine Kleinigkeit gefunden und gefixed. Aber das Problem besteht im Multiuser Mode immer noch.

Kann mir da jemand helfen? Danke schonmal im voraus.

pertze

PS: mit "crash" mein ich eigentlich Stromausfall

 

[asg]

Schalte doch mal softupdates ab. Ich entsinne mich das es da mal was gab, ist aber schon was her und ich selbst hatte da nie ein Problem mit.

 

[pertze]

Ok, das Abschalten von Softupdates hat leider nichts gebracht.

Ich habe dann mal den Background fsck ausgeschalten. Beim nächsten Reboot hat er dann natürlich gleich beim Booten den fsck erzwungen und da konnt ich sehen, dass es sich um das device ar0s2d handelt auf dem ca. 300 GB Daten liegen. Er findet einige Fehler, aber fsck kann die entsprechenden Blöcke und Sektoren nicht schreiben

Ich habe die Ausgabe von fsck mal hier geuppt: http://whuut.net/misc/fsck.log

Ich kann fsck so oft aufrufen wie ich will, aber das Filesystem bekomme ich nicht clean. Als Übergang habe ich das FS erstmal readonly gemounted um wenigstens an die Daten zu kommen. Alle anderen Partitionen auf dem gleichen Device, aber anderem Slice sind clean und i.O.

Was kann ich jetzt tun?

 

[Kamikaze]

Klingt nach einem mechanischen Defekt. Solche defekte wachesen mit der Zeit, weil durch Kratzer auf der Scheibe Staub in der Festplatte entsteht, der die Platte weiter zerstört.
Das heißt, sofort retten was du kannst und die Platte tauschen. Hoffentlich hast du immer fleißig deine Backups gemacht.

 

[pertze]

Das Device ar0s2d ist ein Raid 1 aus zwei Western Digital Platten der Raid Edition, die extra für den 24x7 Betrieb ausgelegt sind. Beide Platten sind ca. erst 1 Jahr alt. Von daher bin ich irgendwie skeptisch ob das Verschleißerscheinungen sein sollen.

Und wie stelle ich jetzt fest welche Platte hier defekt sein soll, es werden doch wohl kaum beide sein? Wie gesagt, der Server ist einfach im laufenden Betrieb ausgegangen als unsere USV gestern die Hufe hoch gerissen hat

Würde es etwas bringen, die betroffene Partition zu löschen, das Dateisystem neu zu erstellen und anschließend die Daten wieder zurückzuspielen?

 

[asg]

Neue Hardware schützt vor Fehlern nicht. Ich habe schon neue HW bekommen die von Anfang an defekt war, oder nach erstmaligen Betrieb zeigte das sie defekt ist.

Entweder ist das FS zerschossen, die Platte hat einen defekt oder das RAID ist gaga.
SCSI? Dann jubel camcontrol rüber und schau nach wieviel Fehler die Platte hat, bzw. wie die Zahl der wachsenden Fehler aussieht.

FS platt machen? Sicher, wenn Du die Daten als Backup hast, dann mach es platt, erstell es neu.

 

[pertze]

Dann wird das FS defekt sein, nur ich dachte es gäbe noch eine Möglichkeit das zu fixen ohne gleich ne Platte auszutauschen oder das FS neu zu erstellen.
Ein Backup der 300 GB Daten habe ich natürlich nicht. Ich würde die jetzt irgendwo zwischenspeichern und wieder zurückschreiben.

Ich mein die Daten auf den nicht lesbaren Blöcken sind eh weg. Das eine Verzeichnis bspw. ist nun leer und somit würde ich diese Daten bei der Kopieraktion sowieso entgültig verlieren. Das ist auch nicht weiter tragisch, da es keine sensiblen Daten waren. Mir geht eigentlich nur darum das FS wieder clean zu kriegen um es wieder rw zu mounten.

 

[thyrver]

. Mir geht eigentlich nur darum das FS wieder clean zu kriegen um es wieder rw zu mounten.

Dann halte ich den Ansatz,
.) die Daten temporär woanders hin zu kopieren (vielleicht gleich aufs neue Backupmedium),
.) die betroffene Partition zu löschen,
.) neu zu erstellen,
.) mit newfs zu formatieren und
.) die Daten wieder zurück zu kopieren
für die sauberste Lösung.

Wenn Zeit kein ultimativ limitierender Faktor ist, könntest du ein Hardwaretesttool des entsprechenden Festplattenherstellers noch die Platten überprüfen lassen.

 

[pertze]

Theoretischerweise müsste ich doch - ohne die Partition vorher zu löschen und wieder anzulegen - einfach ein newfs auf die Partion machen können, oder? Denn ich bekomme einen input/output error mit einer Sektorangabe bei

newfs -U /dev/ar0s2d

Habe auch mal einen extended SMART Test auf beide Platten losgelassen, der ca. 2h dauerte, aber keinen Fehler feststellen konnte.

 

[thyrver]

Theoretischerweise müsste ich doch - ohne die Partition vorher zu löschen und wieder anzulegen - einfach ein newfs auf die Partion machen können, oder?

Ja. Das habe ich eigentlich auch oben gemeint, als ich oben "Partition löschen" geschrieben habe.

Denn ich bekomme einen input/output error mit einer Sektorangabe bei

newfs -U /dev/ar0s2d

Habe auch mal einen extended SMART Test auf beide Platten losgelassen, der ca. 2h dauerte, aber keinen Fehler feststellen konnte.

Dann würde ich ein Low Level Format mit dem Festplatten-Administrationsprogramm des Herrstellers über die Platte(n) drüber laufen lassen.

Ich hatte mal eine ähnliche Situation, ebenfalls fehlerhafte Sektoren (also solche, auf die nicht mehr geschrieben bzw. von denen nicht mehr gelesen werden konnte). Das wurde aber im S.M.A.R.T Error Log gelogt und ein Extended SMART Test hat die Fehler ebenfalls gefunden. Das Low Level Format hats gerichtet. Die Platte ist nach wie vor im Einsatz, allerdings nicht für kritische Daten und nur mit Backup.