Re: Vinum Probleme. Inode kann nicht gelöscht werden

On Fri, May 21, 2004 at 09:58:16AM +0200, Thomas Vogt wrote:
> Hallo Greg
>
> Am Fr, den 21.05.2004 schrieb Greg 'groggy' Lehey um 1:10:
> > Ich helfe gerne, wenn es Probleme gibt, aber man könnte mir mindestens
> > soweit helfen, dass man mir wichtige Vorgänge nicht verschweigt.
>
>
> Ich muss vorausschicken, dass ich schon laenger an diesem Fehler
> rumdoktore ... deshalb koennte das eine oder andere untergegangen sein
> ... ich verschweige jedoch nichts wissentlich - weshalb sollte ich auch,
> ich will meine Daten wieder :)

Mmmm.

> Nach dem Stromausfall klappte es mit dem fsck nicht mehr, jedoch
> arbeiten konnte ich mit dem FS trotzdem noch. Also arbeitete ich weiter,

Nicht unbedingt eine gloreiche Idee.
Passt auch nicht zu obigem Wunsch nach Datenrettung.
Wenn ein fsck nicht klappt, dann hat das inder Regel sehr sehr ernste
Hintergründe die man nicht ignorieren sollte.

> mit der Hoffnung in den Mailinglisten usw mal eine Loesung zu finden.
> In letzter Zeit schmirrte das System vorallem beim Schreiben länger
> desto mehr ab. Gestern Nacht startete vinum dann nur noch im degraded
> Status und ich handelte eigentlich nach
> http://www.vinumvm.org/vinum/replacing-drive.html
>
> Ich denke mit dem Startvorgang meinst Du : start vol1.p0.s1
> -> Schmirrte bei 99% ab
>
> gleichzeitig kam eine Meldung, dass das FS nicht genuegend mbuf hat
> (leider wurde die Meldung nicht ins /log/message geschrieben)

mbuf ist eine Socketgeschichte, also Netzwerk usw...
Ein Filesystem braucht sowas nicht, solange es nicht im Netz arbeitet
wie z.B. NFS.

> Was mir noch aufgefallen ist:
>
> May 21 00:22:10 ccc kernel: vinum: null rqg
> May 21 00:22:10 ccc kernel: vinum: null rqg

Das ist nicht gut, aber wenn das IO System nicht sauber arbeitet
wundert mich das jetzt nicht sonderlich und mag ein Folgefehler sein.

> Zur Zeit kann ich das FS nur noch read-only mounten und ich kopiere alle
> brauchbare Daten noch auf andere Platten und erwarte den engueltigen GAU
> :)

Das solltest du in der Tat tun.
Ein vorhandenes Backup wäre jetzt natürlich einfacher...

> Mich interessiert vorallem, was ich bei
>
> cannot alloc xxxxxx bytes for inoinfo
> fsck_ufs: bad inode number xxxxxx to nextinode
>
> tun kann um ein aehnliches Problem in Zukunft zu vermeiden.

Über eine Mögliche Ursache hast du uns ja leider noch nichts erzählt.
Du solltest wissen, dass IDE bei aktivierten Schreibcache eigendlich
kein funktionierendes RAID ergeben kann.
Ein einziger Stromausfall reicht für eine asyncronität der Subdisks
aus - und gerade bei R5 kann man das erst bemerken wenn die Parität
gebraucht wird.
Du solltest zumindest ab und an mal einen checkparity machen.

Eine andere Variante ist allerdings, dass die Maschine tatsächlich
zu wenig Speicher für den fsck hatte.
Lässt sich aber nur spekulieren, da wir nicht wissen wie das FS
angelegt wurde, welche Anzahl Files darauf sind und wie die Maschine
ausgestattet ist.
Über die Art der Platten und Controller sind wir auch nicht informiert.
Wir wissen nicht mal ob zum Zeitpunkt der obigen fsck Meldung swap
aktiv war oder nicht.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message