• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Zerschossener ZFS-Pool wiederherstellbar?

jmt

Well-Known Member
Themenstarter #1
Nachdem ich meinen Root-Pool erfolgreich auf einen Mirror überführt hatte wollte ich mich dem Problem Pool-Renaming annehmen. Im zugehörigen Thread gab es auch den Verweis auf eine Live-Distro. Die hatte ich aber nicht zur Hand, also dachte ich mir, mache ich das alte Bäumchen wechsel dich Verfahren. Mein alter Root-Pool heißt sys, mein neuer sys0. Ich bootete sys0 und habe sys in sys1 umbenannt. Danach sys1 gebootet und sys0 in sys umbenannt.
Leider behauptet der Alte Pool immer noch sys zu heißen. Das wäre nicht so schlimm, würde er jetzt nicht auch noch den Fehler ZFS-8000-5E werfen.
Code:
 state: FAULTED
status: One or more devices could not be used because the the label is missing 
        or invalid.  There are insufficient replicas for the pool to continue
        functioning.
action: Destroy and re-create the pool from a backup source.
Nun frage ich mich, wie ich an das Label komme. Mit zdb -l sys sieht das alles "ganz normal" aus, soweit ich das sagen kann. Es wäre echt klasse, wenn ich den Pool (oder Teile davon) wenigstens lesen könnte. Jegliche Hilfe ist wilkommen!
 

jmt

Well-Known Member
Themenstarter #3
zpool import sieht den Pool nur unter den Namen sys. Andere "unbekannte" Pools sind nicht da. Auch stimmt die guid des Pools mit der Ausgabe von zdb -l auf dem Device überein.
 

jmt

Well-Known Member
Themenstarter #4
Anbei die Daten des Pools:
Code:
zpool import
   pool: sys
     id: 874712540419822651
  state: FAULTED
 status: One or more devices contains corrupted data.
 action: The pool cannot be imported due to damaged devices or data.
   see: http://illumos.org/msg/ZFS-8000-5E
 config:

        sys                     FAULTED  corrupted data
          14109631078429946324  FAULTED  corrupted data
Code:
zdb -l /dev/ada0p3
--------------------------------------------
LABEL 0
--------------------------------------------
    version: 28
    name: 'sys'
    state: 1
    txg: 840285
    pool_guid: 874712540419822651
    hostid: 4266313884
    hostname: 'mcp.lf28.net'
    top_guid: 14109631078429946324
    guid: 14109631078429946324
    vdev_children: 1
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 14109631078429946324
        path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b'
        phys_path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b'
        whole_disk: 1
        metaslab_array: 30
        metaslab_shift: 34
        ashift: 12
        asize: 1991803142144
        is_log: 0
        create_txg: 4
--------------------------------------------
LABEL 1
--------------------------------------------
    version: 28
    name: 'sys'
    state: 1
    txg: 840285
    pool_guid: 874712540419822651
    hostid: 4266313884
    hostname: 'mcp.lf28.net'
    top_guid: 14109631078429946324
    guid: 14109631078429946324
    vdev_children: 1
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 14109631078429946324
        path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b'
        phys_path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b'
        whole_disk: 1
        metaslab_array: 30
        metaslab_shift: 34
        ashift: 12
        asize: 1991803142144
        is_log: 0
        create_txg: 4
--------------------------------------------
LABEL 2
--------------------------------------------
    version: 28
    name: 'sys'
    state: 1
    txg: 840285
    pool_guid: 874712540419822651
    hostid: 4266313884
    hostname: 'mcp.lf28.net'
    top_guid: 14109631078429946324
    guid: 14109631078429946324
    vdev_children: 1
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 14109631078429946324
        path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b'
        phys_path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b'
        whole_disk: 1
        metaslab_array: 30
        metaslab_shift: 34
        ashift: 12
        asize: 1991803142144
        is_log: 0
        create_txg: 4
--------------------------------------------
LABEL 3
--------------------------------------------
    version: 28
    name: 'sys'
    state: 1
    txg: 840285
    pool_guid: 874712540419822651
    hostid: 4266313884
    hostname: 'mcp.lf28.net'
    top_guid: 14109631078429946324
    guid: 14109631078429946324
    vdev_children: 1
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 14109631078429946324
        path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b'
        phys_path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b'
        whole_disk: 1
        metaslab_array: 30
        metaslab_shift: 34
        ashift: 12
        asize: 1991803142144
        is_log: 0
        create_txg: 4
 

solarix

Konsolenpenner
#5
zpool import -R /mnt sys schon probiert?

Wird der Pool beim Versuch geblockt?
im Zweifelsfall, von einer Live CD booten, FreeBSD oder Opensolaris/OpenIndiana und mal kucken ob der Pool von der Live CD importierbar ist. Dann den Pool wieder exportieren. Anders wird es wohl nicht gehen.

Alternative aber mit höheren Risiken verbundene Vorgehensweise wäre..... zpool destroy sys

zpool import -D
oder forced
zpool import -Df
 

jmt

Well-Known Member
Themenstarter #6
zpool import -R /mnt sys schon probiert?

Wird der Pool beim Versuch geblockt?
im Zweifelsfall, von einer Live CD booten, FreeBSD oder Opensolaris/OpenIndiana und mal kucken ob der Pool von der Live CD importierbar ist. Dann den Pool wieder exportieren. Anders wird es wohl nicht gehen.

Alternative aber mit höheren Risiken verbundene Vorgehensweise wäre..... zpool destroy sys

zpool import -D
oder forced
zpool import -Df
Code:
root@mcp:~ # zpool import -R /mnt sys
cannot import 'sys': I/O error
        Destroy and re-create the pool from
        a backup source.
Ich habe mittlerweile meinen funktionierenden Root-Mirror auf sys0 (zurück-)umbenannt. Dabei habe ich auch den Cache neu angelegt (zpool.cache), jedoch den alten gesichert. Im alten Cache steht noch der sys1 drin. Ich verstehe nicht, welches Device im fehlt. Die angezeigte ID entspricht der des Devices. Und der Pool bestand ja nur aus einem Device. Irgendwie vermisse ich die entscheidenden Informationen...
 

solarix

Konsolenpenner
#7
Code:
root@mcp:~ # zpool import -R /mnt sys
cannot import 'sys': I/O error
        Destroy and re-create the pool from
        a backup source.
Ich habe mittlerweile meinen funktionierenden Root-Mirror auf sys0 (zurück-)umbenannt. Dabei habe ich auch den Cache neu angelegt (zpool.cache), jedoch den alten gesichert. Im alten Cache steht noch der sys1 drin. Ich verstehe nicht, welches Device im fehlt. Die angezeigte ID entspricht der des Devices. Und der Pool bestand ja nur aus einem Device. Irgendwie vermisse ich die entscheidenden Informationen...
Also jetzt wär ich an dem Punkt wo ich wirklich von einem Live Medium booten würde und erst mal gegen prüfen würde, ob der Pool sich dort importieren und exportieren lässt.

Wenn sich der Pool dort importieren lässt hättest Du zumindest die Bestätigung das der Pool an sich in Ordnung ist..

Jetzt ewig dran rum doktern führt zu keiner Lösung.

Möglicherweise könnte Dir auch noch der Versuch eines Rollbacks mittels zpool -F helfen.

Aber zuvor würde ich den Pool erst mal mit dem Live Medium importieren.


Geben die Messages irgend was her, das dein physikalisches Device irgend einen Schaden haben könnte?
 

jmt

Well-Known Member
Themenstarter #8
Ich habe den Import schon mittels FreeBSD-USB-Image (9.1) versucht. Das gab das gleiche Ergebnis. zpool import -F funktioniert auch nicht. Immer wieder kommt dieser I/O-Error, wobei ich keine Meldung vom OS bekomme. Die Platte ist auch relativ neu (ca. 2 Monate), so dass ich nicht an einen HW-Defekt glaube. Und wie schon geschrieben, ich bekomme keine Meldung vom OS: Nichts auf der Console, nichts in den dmsg, nichts im Log! :confused:
Wenn ich wenigstens wüsste, was er denn da lesen oder schreiben möchte...
Gibt es denn kein Tool, mit dem man auf so einem Device lesen kann? Alternative mount-optionen, etc.?

Ich werde jetzt mal mfsbsd testen...
 

solarix

Konsolenpenner
#9
Ich habe den Import schon mittels FreeBSD-USB-Image (9.1) versucht. Das gab das gleiche Ergebnis. zpool import -F funktioniert auch nicht. Immer wieder kommt dieser I/O-Error, wobei ich keine Meldung vom OS bekomme. Die Platte ist auch relativ neu (ca. 2 Monate), so dass ich nicht an einen HW-Defekt glaube. Und wie schon geschrieben, ich bekomme keine Meldung vom OS: Nichts auf der Console, nichts in den dmsg, nichts im Log! :confused:
Wenn ich wenigstens wüsste, was er denn da lesen oder schreiben möchte...
Gibt es denn kein Tool, mit dem man auf so einem Device lesen kann? Alternative mount-optionen, etc.?

Ich werde jetzt mal mfsbsd testen...
Ich würde den Import in jedem Fall noch mal mit
Opensolaris/Openindiana oder einem aktuellen Solaris 10u10
probieren, wenn es sich da nicht importieren lässt ist das Ding kaputt,
wahrscheinlich hat es die Metadaten geshreddert.
Also

Im Zweifelsfall noch mal mit

zpool import -nfF sys
zpool import -nFX sys

ran gehen.

Nur aus Interessse, was hat der ZDB bei zdb -e ausgegeben?

Kommt zdb auch mit einem I/O Error zurück?
 

jmt

Well-Known Member
Themenstarter #10
zdb -e gibt folgendes aus:
Code:
root@mcp:~ # zdb -e sys

Configuration for import:
        vdev_children: 1
        version: 28
        pool_guid: 874712540419822651
        name: 'sys'
        state: 1
        hostid: 4266313884
        hostname: 'mcp.lf28.net'
        vdev_tree:
            type: 'root'
            id: 0
            guid: 874712540419822651
            children[0]:
                type: 'disk'
                id: 0
                guid: 14109631078429946324
                phys_path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b'
                whole_disk: 1
                metaslab_array: 30
                metaslab_shift: 34
                ashift: 12
                asize: 1991803142144
                is_log: 0
                create_txg: 4
                path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b'
zdb: can't open 'sys': Input/output error
 

jmt

Well-Known Member
Themenstarter #11
Code:
 zdb -vvvvXe sys
beschäftigt zumindest die Platte und hört nicht gleich mit einem I/O-Error auf...
:zitter:
 

jmt

Well-Known Member
Themenstarter #12
Code:
root@mcp:~ # zdb -vvvvXe sys

Configuration for import:
        vdev_children: 1
        version: 28
        pool_guid: 874712540419822651
        name: 'sys'
        state: 1
        hostid: 4266313884
        hostname: 'mcp.lf28.net'
        vdev_tree:
            type: 'root'
            id: 0
            guid: 874712540419822651
            children[0]:
                type: 'disk'
                id: 0
                guid: 14109631078429946324
                phys_path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b'
                whole_disk: 1
                metaslab_array: 30
                metaslab_shift: 34
                ashift: 12
                asize: 1991803142144
                is_log: 0
                create_txg: 4
                path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b'
zdb: can't open 'sys': Too many open files
Was soll das denn nun? :confused:
Was treibt zdb überhaupt und wie kann ich das "Too many open files" umgehen?

Nachtrag:
limit -n unlimited hilft nicht...
 
Zuletzt bearbeitet:

solarix

Konsolenpenner
#13
Ehrlich ich würd da nimmer lang rum doktern... versuch es wie ich vorgeschlagen hab mit Solaris, wenn es da nicht funktioniert... hast Du hoffentlich ein funktionierendes Backup.
 

jmt

Well-Known Member
Themenstarter #14
Ich lade Solaris ja gerade herunter. Das braucht aber noch eine Stunde. Und zweitens kenne ich mich mit Solaris gar nicht aus. Ich lade gerade das openindiana live usb-image build 151a5 herunter. Ist das richtig?
 

solarix

Konsolenpenner
#15
Ich lade Solaris ja gerade herunter. Das braucht aber noch eine Stunde. Und zweitens kenne ich mich mit Solaris gar nicht aus. Ich lade gerade das openindiana live usb-image build 151a5 herunter. Ist das richtig?
Solaris ist kein Hexenwerk. Mit dem Openindiana kann man schon was anfangen.

Loginname jack
Password jack

pfexec zpool import

Das pfexec vorne dran nicht vergessen.....
Alternativ bei Oracle

Die offizielle Live DVD/CD von Solaris 11.1 ziehen da ist auch der aktuellste ZFS Codes und die aktuellen ZFS Patche drin.
Es ist auf jeden Fall einen Versuch wert.

Viel Erfolg ich kuck heut Abend noch mal rein.
 

jmt

Well-Known Member
Themenstarter #16
Herr je, Solaris bootet, aber jetzt kann er mit den Pfaden nichts anfangen. Es gibt ja auch kein /dev/gptid/3094...
 

jmt

Well-Known Member
Themenstarter #17
Die einzige neue Erkenntnis ist, dass unter Solaris die ersten beiden Label kaputt sind (Failed to unpack label). Importiert man den Pool mit zpool import -V, dann sagt einem ein zpool status, dass er das Device nicht findet. Als bisheriges Device steht das alte. Ein zdb -Fe gibt immer noch ein "zdb: can't open 'sys': No such device or address". Und in der Ausgabe findet sich der Pfad nach /dev/gptid. Meine Versuche, einen passenden Link anzulegen scheiterten aber kläglich, da zdb dann meinte, es wäre kein block-Device. Der gleiche Sym-Link als /dev/dsk/c4t0d0p0 funktioniert aber. Es muss doch möglich sein, dass man so einen Pool wieder reaktivieren kann...
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#20
Als letzte Möglichkeit könntest du auf freebsd-fs@ fragen. Dort sind sehr kompetente Personen und man ist vor allem immer an Fehlerberichten interessiert. Alles in allem ist ZFS zwar inzwischen sehr zuverlässig, aber einige scharfe Kanten bleiben noch. Und die findet man halt nur, wenn sich Betroffene melden.

Sonst könnte ich noch einen 10-CURRENT-Snapshot in den Ring werfen. Dort gibt es eine komplett neue Logik zum Erkennen der Pools auf Platten, die im Fall des Rootpools sogar ohne den zpool.cache auskommt. Aber große Hoffnungen würden ich mir da nicht machen.
 

solarix

Konsolenpenner
#21
Ja, mehrfach sogar. Ob ID oder Name macht keinen Unterschied.
Das ist aber höchst seltsam...... ich hab Pools unter Solaris importiert bekommen die unter
anderen Systemen erstellt wurden und umgekehrt....

Wenn gar nix mehr geht..... und Du auf der Mailingliste keine Antwort bekommst würd ich den Pool zerstören und dann mal versuchen unter Solaris den Pool mit -D oder -Df wieder her zu stellen..

Kann es sein, ich selber kann es nicht beurteilen.... das Er sich an dem GPT Label verschluckt?
 
Zuletzt bearbeitet:

jmt

Well-Known Member
Themenstarter #22
Okay, bevor ich mein Englisch zusammen krame und mich auf der fs-Mailing-List kundtue, teste ich noch mal 10-Current. Immerhin arbeitet zdb -Xe sys eine ganze Weile. Vielleicht kommt dann ja mal was raus. :rolleyes:
Unter Openiniana kriege ich das nicht zum Laufen. Wieso kann man eigentlich keinen funktionierenden Link auf ein Device anlegen? Die Kommandos brachen alle sofort ab. Und der Pool liegt auf einer GPT-Partition (nicht die erste). Ich habe keine Ahnung, ob Openindiana das verstanden hat. Interessanter Weise sind unter FreeBSD alle 4 Labels wieder lesbar. :confused:
 

solarix

Konsolenpenner
#23
Okay, bevor ich mein Englisch zusammen krame und mich auf der fs-Mailing-List kundtue, teste ich noch mal 10-Current. Immerhin arbeitet zdb -Xe sys eine ganze Weile. Vielleicht kommt dann ja mal was raus. :rolleyes:
Unter Openiniana kriege ich das nicht zum Laufen. Wieso kann man eigentlich keinen funktionierenden Link auf ein Device anlegen? Die Kommandos brachen alle sofort ab. Und der Pool liegt auf einer GPT-Partition (nicht die erste). Ich habe keine Ahnung, ob Openindiana das verstanden hat. Interessanter Weise sind unter FreeBSD alle 4 Labels wieder lesbar. :confused:
Wenn ich mir diesen Thread hier durch lese .... könnt ich mir gut vorstellen das er wegen des GPT Labels nicht zurecht kommt...

Abgesehen davon Solaris legt seinen Device Tree mittels devfsadm beim Booten an...
mit mknod kann man aber immer noch Links anlegen.

Eigentlich sollte ihm beim Import das Device ob
/ada0 oder c0t0d0
völlig scheissegal sein, weil er eigentlich die Platte als ganzes antatscht und sich auf die Metadaten verlässt.. sobald Er den Uberblock findet sollte das eigentlich passen.. *kopfkratz*
 

jmt

Well-Known Member
Themenstarter #24
So, mit FreeBSD 10 gibt es bei zdb -Xe sys mal einen Stacktrace im dmesg:
Code:
lock order reversal:
 1st 0xfffffe003184c668 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:851
 2nd 0xfffffe0031832e28 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2161
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff886417d3f0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff886417d4a0
witness_checkorder() at witness_checkorder+0xc47/frame 0xffffff886417d520
__lockmgr_args() at __lockmgr_args+0x6e2/frame 0xffffff886417d650
vop_stdlock() at vop_stdlock+0x3c/frame 0xffffff886417d670
VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd0/frame 0xffffff886417d690
_vn_lock() at _vn_lock+0xab/frame 0xffffff886417d700
vget() at vget+0x70/frame 0xffffff886417d750
devfs_allocv() at devfs_allocv+0xfd/frame 0xffffff886417d7a0
devfs_root() at devfs_root+0x43/frame 0xffffff886417d7d0
vfs_donmount() at vfs_donmount+0xf92/frame 0xffffff886417da60
sys_nmount() at sys_nmount+0x72/frame 0xffffff886417daa0
amd64_syscall() at amd64_syscall+0x265/frame 0xffffff886417dbb0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff886417dbb0
--- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a966ca, rsp = 0x7fffffffccc8, rbp = 0x7fffffffd230 ---
Erneuter Versuch:
Code:
 zdb -Xe sys

Configuration for import:
        vdev_children: 1
        version: 28
        pool_guid: 874712540419822651
        name: 'sys'
        txg: 840285
        state: 1
        hostid: 4266313884
        hostname: 'mcp.lf28.net'
        vdev_tree:
            type: 'root'
            id: 0
            guid: 874712540419822651
            children[0]:
                type: 'disk'
                id: 0
                guid: 14109631078429946324
                phys_path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b'
                whole_disk: 1
                metaslab_array: 30
                metaslab_shift: 34
                ashift: 12
                asize: 1991803142144
                is_log: 0
                create_txg: 4
                path: '/dev/gptid/3094758a-13a1-11e2-a7c0-bc5ff437dd0b'
zdb: can't open 'sys': Too many open files
Diesmal gibt es keine neue dmesg. Vielleicht auch ein anderes Problem...
 
Zuletzt bearbeitet: