gvinum vergißt subdisk

volker68

Well-Known Member
Hallo Forumsteilnehmer!

First post here... Da ich gerade nicht email schreiben kann und somit nicht an die Mailinglisten komme, muß ich über's Forum gehen. Ich hoffe, hier liest jemand mit, der mir einen Hinweis geben kann.

FreeBSD RELENG_6 (recent cvsup + compile)

Meine Maschine hat in den letzten Tagen mehrfach nach Panic gebootet (läuft halt die aktuelle Beta drauf... - da muß man sowas in Kauf nehmen).

Dummerweise hatte ich mal vor ca. 9 Monaten mit gvinum gespielt und eine Platte unter gvinum in mehrere Volumes aufgeteilt. Danach bin ich nie dazu gekommen, gvinum wieder zu verbannen. Nun nach den Panics der letzten Tage kommt gvinum hoch, kennt auch noch alle Volumes und Plexes, aber (fast) keine Subdisks mehr.

Leider finde ich keine gespeicherte Fassung von `gvinum printconfig' und nach meinem Verständnis benötigt man diese Ausgabe, um verlorene on-disk Metadaten für gvinum zu rekonstruieren.

Aktuell zeigt gvinum gerade noch die allererste Subdisk (von insgesamt 8). Kennt jemand eine Möglichkeit, die Metadaten von gvinum auch ohne Ausgabe von printconfig zu rekonstruieren? Dummerweise ist die Maschine u.a. mein Gateway und dummerweise hatte ich /usr und Homeverzeichnisse gvinum anvertraut. Somit kommt die Maschine nicht hoch.

Besten Dank für jegliche Hinweise... wenn ich's nicht hinbekomme, ist eine Neuinstallation fällig und einige Tage, um ein über Jahre konfiguriertes System wieder geradezubiegen. :(
 
Gvinum ist noch NICHT stable. Am Besten, du gehst zurück auf die Version, bei der dein Array noch funktioniert hat, und verwendest die bis auf Weiteres.
Es müsste aber auch reichen, wenn du nur gvinum downgradest:
cvsup altes-supfile -i src/sys/geom/vinum
für das Kernel-Modul
cvsup altes-supfile -i src/sbin/gvinum
für das Userland-Programm
Treten die Panics im Zusammenhang mit gvinum auf?
 
Jegliche Antworten haben sich erledigt. Ich hab's hinbekommen.

Wer dieses Problem auch mal haben sollte, ich bin in etwa so vorgegangen:

Die Partition, in der gvinum die Volumes usw. hält, nach einer Zeichenfolge wie 0200 (oktal!! = 0x128) und nachfolgendem Slash + mountpoint absuchen. Die gefundene Zeichenkette ist bei einem ufs-Filesystem an Stelle 0x100d3, d.h. sobald man die korrekte Position gefunden hat, rechnet man die entsprechende Anzahl Bytes zurück und hat im gvinum-Datenwust den Anfang des Volumes (filesystem) gefunden.

Dann bastelt man sich eine gvinum-Konfigurationsdatei zusammen, in der man für die entsprechenden Volumes die Offsets ab slice-Anfang reinschreibt. Wenn man alles richtig gemacht hat, dann kommt man so wieder (trotz verlorener on-disk Metadaten) an die von gvinum verwalteten Dateisysteme heran.

Viel Spaß beim rechnen... :)
 
free said:
Gvinum ist noch NICHT stable. Am Besten, du gehst zurück auf die Version, bei der dein Array noch funktioniert hat, und verwendest die bis auf Weiteres.
Es müsste aber auch reichen, wenn du nur gvinum downgradest:
cvsup altes-supfile -i src/sys/geom/vinum
für das Kernel-Modul
cvsup altes-supfile -i src/sbin/gvinum
für das Userland-Programm
Treten die Panics im Zusammenhang mit gvinum auf?

Danke für die Antwort, aber ich denke, das hätte mir ohnehin nicht geholfen. Für die von Dir vorgeschlagene Lösung war es ja bereits zu spät, da gvinum die on-disk Metadaten verloren hatte.

Daß gvinum nach wie vor Beta ist, ist mir bekannt. Ich hatte es vor einigen Monaten mal für Spielereien ausprobiert und habe es hinterher nicht wieder rückgängig gemacht (nenn es Faulheit...).

Die Panics (soweit ich sie kurz vor dem Reboot noch sehen konnte) kamen wohl immer nach CRC-Fehlern, die gvinum gemeldet hat. Meine Platten sind aber tadellos (LVD-SCSI). Die GDL ist absolut sauber und auch S.M.A.R.T. hat nie Probleme mit den Platten gemeldet.

Ich vermute also, daß an gvinum zwischen 6.1-BETA2/3 und 6.1-RC1/2 etwas verbastelt wurde, was zu den CRC-Fehlern geführt hat. Mit 6.0-RELEASE bzw. RELENG_6 vor 6.1-BETA3 hat gvinum keine Probleme bereitet (außer daß es die Plattenzugriffen grottenlangsam gemacht hat).

Wie gesagt, das Problem hat sich erledigt, da ich die Positionen der Filesysteme per Hand innerhalb des gvinum-slices berechnen konnte und dadurch die Filesysteme durch dump gerettet habe. Damit habe ich meine gvinum-Spielerei endlich wieder (gezwungenermaßen) bereinigt und bin wieder um einiges schlauer. :)

Dennoch besten Dank für Deine Antwort.
 
Das klingt äußerst interessant. Solche Anleitungen sucht man meistens vergeblich im Falle des Falles. Kannst Du die Berechnungen anhand eines Beispiels skizzieren? Wäre auch wichtig für Dich. Man vergisst mit der Zeit.

Eine wichtigere Sache wäre, diesen (Un)Fall zu rekonstruieren und einen PR zu machen, wenn's möglich ist. Bist Du auch sicher, dass die gvinum-Konfiguration nun im sicheren Bereich ist? Weißt Du womit sie überschrieben worden ist?
 
Nakal,

ok, ich werde mal versuchen, den Rekonstruktionsweg hier im Forum nachzustellen. Allerdings muß ich das aus dem Kopf und anhand einiger handschriftlicher Notizen machen, da ich mir mein System nicht wieder kaputtbasteln will, um hier dann hardcopies zu liefern. :)

Einen PR zu erzeugen ist mir nichts, wenn ich keine exakten Informationen und keine Debugger-Ausgaben habe. Ich habe nur ein paar CRC-Fehler gesehen und das kurz vor dem Reboot.

Mein ganz konkretes Problem lag ja darin, daß ich weder ein gvinum-dump (printconfig) mit den exakten Offset-Positionen und Volume-Längen hatte und die on-disk Metadaten zum Teil zerstört waren. Vermutlich (!!) hat gvinum die durch die CRC-Fehler "vergessen". Nun habe ich alle Daten von den gvinum-Volumes (auf eine Reserve-Platte) wieder auf normale Dateisysteme in normalen Slices umgeschaufelt und nun dürfte das nicht mehr passieren. Wenn gvinum irgendwann mal vollständig implementiert ist und stabil läuft, werde ich bestimmt wieder auf gvinum umstellen. Die Idee ist grundsätzlich eine feine Sache.

Ich probiere mal die Dokumentation der gvinum-Rekonstruktion, aber bitte etwas Geduld. Ich weiß nicht, ob ich das heute noch hinbekomme (nachdem ich nun gerade einen Ausfall von fast 30 Stunden überstanden habe).
 
Back
Top