JayanWarden
Dabbler
- Joined
- Nov 26, 2017
- Messages
- 22
Hello everyone,
after somehardware failure I need to import my old ZFS pool on a new Server with the Log devices missing.
However, zpool import -f return the following error message:
now at first I didn't see which devices are responsible for the error message "missing device".
But then it occurred to me that I had configured a mirrored log device for this pool.
I tried the following commands to no avail:
zpool import -f
zpool import -fF
zpool import -fm
zpool import -f -m
zpool import -fFX
zpool import -fFX -m
zpool import -fmFX
zdb gives the following information:
So I guess I can't import because
children[1]:
type: 'missing'
id: 1
guid: 0
are missing.
But why doesn't -m work? The two missing devices were merely Log devices, why doesn't ZFS want to import the pool when I specify -m and -X (and any combination of recovery flags) ?
Is my pool doomed? all pool data drives are definitely available and in working condition.
Thanks for reading, help greatly appreciated!
after somehardware failure I need to import my old ZFS pool on a new Server with the Log devices missing.
However, zpool import -f return the following error message:
zpool import -f
pool: Transfer
id: 17969070376272401836
state: UNAVAIL
status: The pool was last accessed by another system.
action: The pool cannot be imported due to damaged devices or data.
see: http://zfsonlinux.org/msg/ZFS-8000-EY
config:
Transfer UNAVAIL missing device
raidz2-0 ONLINE
sde ONLINE
sdf ONLINE
sdc ONLINE
sdd ONLINE
sdb ONLINE
now at first I didn't see which devices are responsible for the error message "missing device".
But then it occurred to me that I had configured a mirrored log device for this pool.
I tried the following commands to no avail:
zpool import -f
zpool import -fF
zpool import -fm
zpool import -f -m
zpool import -fFX
zpool import -fFX -m
zpool import -fmFX
zdb gives the following information:
Code:
Configuration for import: vdev_children: 2 version: 5000 pool_guid: 17969070376272401836 name: 'Transfer' state: 0 hostid: 2424241580 hostname: '' vdev_tree: type: 'root' id: 0 guid: 17969070376272401836 children[0]: type: 'raidz' id: 0 guid: 15604554527484725918 nparity: 2 metaslab_array: 42 metaslab_shift: 38 ashift: 12 asize: 39997054648320 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 14877975940621952018 whole_disk: 1 DTL: 427 create_txg: 4 path: '/dev/sde2' children[1]: type: 'disk' id: 1 guid: 7682865178649624056 whole_disk: 1 DTL: 161 create_txg: 4 path: '/dev/sdf2' children[2]: type: 'disk' id: 2 guid: 16365352912611834826 whole_disk: 1 DTL: 425 create_txg: 4 path: '/dev/sdc2' children[3]: type: 'disk' id: 3 guid: 8090733727149963468 whole_disk: 1 DTL: 424 create_txg: 4 path: '/dev/sdd2' children[4]: type: 'disk' id: 4 guid: 1792929707086124561 whole_disk: 1 DTL: 423 create_txg: 4 path: '/dev/sdb2' children[1]: type: 'missing' id: 1 guid: 0 rewind-policy: rewind-request-txg: 18446744073709551615 rewind-request: 2 MOS Configuration: version: 5000 name: 'Transfer' state: 0 txg: 5645149 pool_guid: 17969070376272401836 hostid: 2424241580 hostname: '' com.delphix:has_per_vdev_zaps vdev_children: 2 vdev_tree: type: 'root' id: 0 guid: 17969070376272401836 children[0]: type: 'raidz' id: 0 guid: 15604554527484725918 nparity: 2 metaslab_array: 42 metaslab_shift: 38 ashift: 12 asize: 39997054648320 is_log: 0 create_txg: 4 com.delphix:vdev_zap_top: 36 children[0]: type: 'disk' id: 0 guid: 14877975940621952018 path: '/dev/gptid/ae7282f0-ce7d-11e7-b88e-ac1f6b1d1286' whole_disk: 1 DTL: 427 create_txg: 4 com.delphix:vdev_zap_leaf: 37 children[1]: type: 'disk' id: 1 guid: 7682865178649624056 path: '/dev/gptid/e2376a92-3c65-11e9-9b53-ac1f6b1d1286' whole_disk: 1 DTL: 161 create_txg: 4 com.delphix:vdev_zap_leaf: 160 children[2]: type: 'disk' id: 2 guid: 16365352912611834826 path: '/dev/gptid/b04e806f-ce7d-11e7-b88e-ac1f6b1d1286' whole_disk: 1 DTL: 425 create_txg: 4 com.delphix:vdev_zap_leaf: 39 children[3]: type: 'disk' id: 3 guid: 8090733727149963468 path: '/dev/gptid/b0fa2215-ce7d-11e7-b88e-ac1f6b1d1286' whole_disk: 1 DTL: 424 create_txg: 4 com.delphix:vdev_zap_leaf: 40 children[4]: type: 'disk' id: 4 guid: 1792929707086124561 path: '/dev/gptid/b1f286b6-ce7d-11e7-b88e-ac1f6b1d1286' whole_disk: 1 DTL: 423 create_txg: 4 com.delphix:vdev_zap_leaf: 41 children[1]: type: 'mirror' id: 1 guid: 17628069014945562014 metaslab_array: 89 metaslab_shift: 26 ashift: 12 asize: 8585216000 is_log: 1 create_txg: 157600 com.delphix:vdev_zap_top: 49 children[0]: type: 'disk' id: 0 guid: 9523356891319150884 path: '/dev/ada0p1' whole_disk: 1 DTL: 422 create_txg: 157600 com.delphix:vdev_zap_leaf: 50 children[1]: type: 'disk' id: 1 guid: 10486496941185256776 path: '/dev/ada1p1' whole_disk: 1 DTL: 421 create_txg: 157600 com.delphix:vdev_zap_leaf: 51 features_for_read: com.delphix:hole_birth com.delphix:embedded_data
So I guess I can't import because
children[1]:
type: 'missing'
id: 1
guid: 0
are missing.
But why doesn't -m work? The two missing devices were merely Log devices, why doesn't ZFS want to import the pool when I specify -m and -X (and any combination of recovery flags) ?
Is my pool doomed? all pool data drives are definitely available and in working condition.
Thanks for reading, help greatly appreciated!
Last edited: