Import eines unvollständigen zpools

[ron2105]

Hallo,

ich glaube, dass ich mir gestern selbst ins Knie geschossen habe.
Mein Backup-Server mit einem zpool (rpool 20GB) und einem raidz2 (7x1TB + log-device 8GB) für Daten hat sich verabschiedet. Da ich sowieso noch einen IPCop mit einem alten PC aufsetzen wollte (dafür die 8GB-HDD) und mein neues log- und cache-device ein mirror aus zwei SDDs werden sollen, habe ich mich erst einmal an den IPCop gesetzt. Cop läuft ...... nun der neue Backup-Server ........ OpenSolaris 2009.06 installiert, Repo auf /dev umgestellt, Alles aktualisiert und Upgrade des ZFS auf Version 22. Nun nur noch den Daten-zpool importieren  ... fertig!  .... AprilApril - obwohl schon Mai ist !!!!!!!
ein:
zpool import
gibt:
The pool was last assessed by another system. (logisch)
The pool cannot imported due damaged devices or data. (aber da fehlt ja nur das log-device, der Rest sollte importierbar sein)

das ganze mit: -f
gibt:
cannot import 'tank1': one or more devices is currently unavailable
        Destroy and re-create the pool from
        a backup source.
auf alle anderen Versuche (replace, detach, import -D, online <neues dev> usw.)
kommt ein:
cannot open 'tank1': no such pool

Den heutigen Tag habe ich mit Tante Google verbracht, aber ohne Erfolg.
Ich hoffe jemand kann mir einen Tipp dazu geben.
Vielen Dank für Eure Bemühungen.

Gruß
Ron

[Hexxer]

Hi,

ich geh mal davon aus das Du den Troubleshoootingguide abgearbeitet hast ?
http://www.solarisinternals.com/wiki/index.php/ZFS_Troubleshooting_Guide

MFG

[ron2105]

Hallo,

vielen Dank für Deine Antwort.
Ja, habe ich u.a. abgearbeitet. Mein Problem scheint es ja zu sein, dass ich das log-device UND die Systemplatte nicht mehr habe. Ich hätte besser nach dem Verlust der Systemplatte den Rechner neu aufsetzen sollen, den zpool importieren und dann erst das log-device tauschen sollen. So fehlen mir jetzt die Wiederherstellungsdaten des log-device auf der Systemplatte zu diesem zpool. Das kommt dabei raus, wenn man so dämlich ist, 2 Schritte mit einem Mal zu machen.
Ich habe auch schon versucht, mit der alten log-HDD und einem nachgebauten raidz2 ein gefaktes log-device zu erzeugen, um es dann dem ursprünglichen zpool unterzuschieben. Aber anscheinend war das Label wohl nicht "passend genug", und wie ich das Label noch weiter anpassen kann, habe ich noch nicht herausgefunden.
Was mich etwas stutzig macht, ist der Umstand, dass erst die Antwort auf den Importversuch lautet: zpool gefunden, aber nicht vollständig "genug", um ihn zu importieren. Alle anderen Versuche devices auszutauschen, hinzuzufügen oder anzumelden, enden mit einem: zpool gibt's nicht, kenn' ich nicht. Das hindert mich ja daran, wieder ein log-device am zpool anzumelden. Das log-device wird ja nur dazu verwendet, das ZFS POSIX-kompatibel zu machen und da ich zum Crashzeitpunkt keine Schreiboperationen auf diesen zpool getätigt habe, kann ich aus Sicht der Datensicherheit sehr gut darauf verzichten. Bei anderen Filesystemen gibt es i.d.R. immer noch eine Möglichkeit, das Ding "mit aller Gewalt" zu mounten (mit der Gefahr von Datenverlust), beim ZFS ist -force leider nicht "force" genug.

[ron2105]

Hallo,

hier ein kleiner Zwischenrapport: immer noch kein Erfolg.
Bei mir beißt sich immer noch die Katze in den Schwanz:
- ein Import des zpools ist nicht möglich, da ein Gerät nicht da ist
und
- das / ein Gerät kann ich nicht ersetzen / hinzufügen / entfernen / reparieren, weil er angeblich den zpool nicht kennt, wenn er nicht importiert ist.
Ich drehe mich im Kreis.

MfG
Ron

[Hexxer]

Hmm, also die daten scheinen ja eh so gut wie weg zu sein.
Man könnte damit mal rumspielen, wobei ich glaub das bringt auch eher nix.
http://www.solarisinternals.com/wiki/index.php/ZFS_Troubleshooting_Guide#Replacing.2FRelabeling_the_Root_Pool_Disk

Bin mir aber nicht sicher was "es" dazu sagt.

[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: [Auswählen]

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

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]

Nebenbei fehlt mir noch ein vernünftiger Editor / Debugger für einzelne Binärdateien, da die "normalen" Editoren in einer vorgegeben Kodierung abspeichern

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.

[linuxdomination]

ich weis schon das diese weisheit viel zu spät kommt, aber ich sage meinen arrays immer das sie diese zfs flush commands ignorieren sollen...ist bei dementsprechender hardware auch ok...natürlich nicht bei irgendwelchen soho sata jbod mist.

[ron2105]

Tja das hätte auch nicht geholfen, da das slog immer noch fehlen würde und ein Import dadurch verhindert wird, auch wenn das dann noch unsinniger wäre. Meine neue Büchse soll ja gespiegelten cache und slog (SDD) bekommen.