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_dataSo 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: