Import eines unvollständigen zpools

Betriebssysteme > Solaris/x86 und OpenSolaris

<< < (2/3) > >>

ron2105:
Naja, rein physisch sind die Daten ja alle noch da, ich bekomm` bloß keinen Zugang. Der genannte Link trifft mein Problem nicht ganz, denn es geht nur um die guid meines ZIL-devices und nicht um das eigentliche Label des gesamten Datenträgers. Hier http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg18347.html und hier http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6733267 geht es genau um das Problem, das ich auch habe. Dort wird gesagt, dass der bug behoben wäre, aber ich habe die neueste Version laufen und es funktioniert nicht, oder habe ich da was falsch verstanden?
Die im Beitrag angesprochene /etc/zfs/zpool.cache ist auf meinem (neu installierten) System eine Binärdatei, die ich demzufolge nicht editieren kann (ich hätte gedacht man könne dort eventuell die Zugehörigkeit eines ZIL-devices zum zpool eintragen / ändern). Ich bin es gewohnt , allerdings unter Linux, im /etc nur Textdateien zu finden, oder kennt jemand die richtige Kodierung?
Mein Rendezvous mit Tante Google wird wohl noch ein wenig andauern (das Pfingstwochenende ist ja lang).
Wenn ich nichts finde, werde ich es doch mal damit versuchen.

Vielen Dank für Eure Vorschläge
Ron

Edit:
hier noch die Antwort auf ein:

--- Code: ---eee@opensolaris:~# zdb -e tank1

Configuration for import:
   vdev_children: 2
   version: 22
   pool_guid: 5048704328421749681
   name: 'tank1'
   state: 0
   hostid: 946038
   hostname: 'opensolaris'
   vdev_tree:
   type: 'root'
   id: 0
   guid: 5048704328421749681
   children[0]:
   type: 'raidz'
   id: 0
   guid: 16723866123388081610
   nparity: 2
   metaslab_array: 23
   metaslab_shift: 30
   ashift: 9
   asize: 7001340903424
   is_log: 0
   create_txg: 4
   children[0]:
   type: 'disk'
   id: 0
   guid: 6858138566678362598
   phys_path: '/pci@0,0/pci8086,244e@1e/pci11ab,11ab@9/disk@0,0:a'
   whole_disk: 1
   DTL: 4345
   create_txg: 4
   path: '/dev/dsk/c7t5d0s0'
   devid: 'id1,sd@SATA_____SAMSUNG_HD103UJ_______S13PJ1BQ709050/a'
   children[1]:
   type: 'disk'
   id: 1
   guid: 16136237447458434520
   phys_path: '/pci@0,0/pci8086,244e@1e/pci11ab,11ab@9/disk@1,0:a'
   whole_disk: 1
   DTL: 4344
   create_txg: 4
   path: '/dev/dsk/c7t0d0s0'
   devid: 'id1,sd@SATA_____SAMSUNG_HD103UJ_______S13PJDWQ317311/a'
   children[2]:
   type: 'disk'
   id: 2
   guid: 10876853602231471126
   phys_path: '/pci@0,0/pci8086,244e@1e/pci11ab,11ab@9/disk@2,0:a'
   whole_disk: 1
   DTL: 4343
   create_txg: 4
   path: '/dev/dsk/c7t6d0s0'
   devid: 'id1,sd@SATA_____Hitachi_HDT72101______STF604MH14S56W/a'
   children[3]:
   type: 'disk'
   id: 3
   guid: 2384677379114262201
   phys_path: '/pci@0,0/pci8086,244e@1e/pci11ab,11ab@9/disk@3,0:a'
   whole_disk: 1
   DTL: 4342
   create_txg: 4
   path: '/dev/dsk/c7t3d0s0'
   devid: 'id1,sd@SATA_____SAMSUNG_HD103UJ_______S13PJ1NQ811135/a'
   children[4]:
   type: 'disk'
   id: 4
   guid: 15143849195434333247
   phys_path: '/pci@0,0/pci8086,244e@1e/pci11ab,11ab@9/disk@4,0:a'
   whole_disk: 1
   DTL: 4341
   create_txg: 4
   path: '/dev/dsk/c7t1d0s0'
   devid: 'id1,sd@SATA_____Hitachi_HDT72101______STF604MH16V73W/a'
   children[5]:
   type: 'disk'
   id: 5
   guid: 11627603446133164653
   phys_path: '/pci@0,0/pci8086,244e@1e/pci11ab,11ab@9/disk@5,0:a'
   whole_disk: 1
   DTL: 4340
   create_txg: 4
   path: '/dev/dsk/c7t4d0s0'
   devid: 'id1,sd@SATA_____SAMSUNG_HD103UJ_______S13PJDWQ317308/a'
   children[6]:
   type: 'disk'
   id: 6
   guid: 15036924286456611863
   phys_path: '/pci@0,0/pci8086,244e@1e/pci11ab,11ab@9/disk@6,0:a'
   whole_disk: 1
   DTL: 4338
   create_txg: 4
   path: '/dev/dsk/c7t2d0s0'
   devid: 'id1,sd@SATA_____Hitachi_HDS72101______JP2921HQ0KMEZA/a'
   children[1]:
   type: 'missing'
   id: 1
   guid: 0
^[[D^[[D

--- Ende Code ---
an dieser Stelle bricht er dann ab und ich muss das Terminalfenster schließen.
Wenn ich dem zpool irgendwie sagen könnte, dass er gar kein separates ZIL-device hat (also durch vdev_children: 1 in der ersten Zeile), oder ihm ein neues zuweisen könnte, wäre alles in Ordnung.

ron2105:
Hallo,

ich habe temporär einen zpool aus Dateien angelegt und diesem ein ZIL-device (ebenfalls eine Datei) zugeordnet, den zpool aufgelöst, und versuche nun schon den ganzen Tag diese Datei zu bearbeiten. In dieser Datei findet manche Angaben im Klartext (Pfad, zpool-Name), aber z.B. die guid scheint nirgends im Klartext hinterlegt zu sein. Nebenbei fehlt mir noch ein vernünftiger Editor / Debugger für einzelne Binärdateien, da die "normalen" Editoren in einer vorgegeben Kodierung abspeichern, was in der Regel zu einem Datenunfall führt (bei mir aber egal, ich brauche ja bloß irgendeine ZIL-Datei für den Import), aber mit 64 MB-großen Dateien??? Für importierte zpools kann man ja den mdb verwenden, funktioniert bei mir natürlich nicht.
Ich bin inzwischen reichlich geschafft. Hat vielleicht noch jemand einen Tipp für mich.

Fleedwood:

--- Zitat von: ron2105 am 22. Mai 2010, 21:53:33 ---Nebenbei fehlt mir noch ein vernünftiger Editor / Debugger für einzelne Binärdateien, da die "normalen" Editoren in einer vorgegeben Kodierung abspeichern

--- Ende Zitat ---

mit dem zpool Problem kann ich leider nicht helfen, aber einen Tipp bzgl. binär Editor hätte ich. Probier mal bvi aus, sofern Du nicht mit vi auf Kriegsfuß stehst.
Hat mir bisher immer gute Dienste beim interaktiven Daten patchen geleistet.

Thomas.

ron2105:
Hallo,

danke für den Tipp, werde ich mal probieren (der vi und ich, wir haben weitgehend Waffenstillstand geschlossen, mit vereinzelten Scharmützeln).

ron2105:
Das Anlegen einer neuen log-Datei, um sie dem zpool unterzuschieben, scheitert an der inkorrekten Prüfsumme des pools, die beim Import überprüft wird. Damit das klappt, müsste man die originale GUID des alten ZIL-devices haben und natürlich das neue müsste mit dem alten identisch sein. Beide Voraussetzungen kann ich nicht erfüllen, sodass mir nur der Weg bleibt, den Import ohne ZIL-device zu versuchen. Seit Version 19 ist ein "Rückbau" eines separaten ZIL-devices möglich, dazu muss der zpool aber aktiv (importiert) sein. Anscheinend sind die Entwickler des ZFS der Meinung, wenn die Daten nicht zu absolut 100 Prozent in Ordnung sind, also das ZIL Teil des zpools und aktuell, dann kann man getrost auf alle Daten verzichten (zumindest seit dem letzten Backup). Bei einem brute-force Import ohne ZIL würde man halt maximal die Transaktionen der letzten 60 Sekunden verlieren, in denen bei mir sowieso nichts stattfand, so verliere ich deutlich mehr.
Ich gebe bei neuen Erkenntnissen wieder Laut.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln