A way to alter ZFS metadata stored on a drive ?
DarkSoul
darksoul at darkbsd.org
Tue Aug 24 15:20:48 UTC 2010
Hi,
I currently am bumping against this bug :
http://bugs.opensolaris.org/view_bug.do?bug_id=6782540
Long story short, I had a dead drive on my pool, I tried to replace it
only to have the planned spare drive die on me.
Which led to this :
pool: prana
state: DEGRADED
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
prana DEGRADED 0 0 0
raidz1 ONLINE 0 0 0
ad16 ONLINE 0 0 0
ad30 ONLINE 0 0 0
ad28 ONLINE 0 0 0
ad18 ONLINE 0 0 0
ad14 ONLINE 0 0 0
raidz1 DEGRADED 0 0 0
ada2 ONLINE 0 0 0
ad4 ONLINE 0 0 0
ad6 ONLINE 0 0 0
ad8 ONLINE 0 0 0
replacing UNAVAIL 0 12.2K 0 insufficient
replicas
16391273719868046777 UNAVAIL 0 14.5K 0 was /dev/ada3/old
17286942469715238412 UNAVAIL 0 14.5K 0 was /dev/ada3
raidz1 ONLINE 0 0 0
ada3 ONLINE 0 0 0
ada1 ONLINE 0 0 0
ada0 ONLINE 0 0 0
ad32 ONLINE 0 0 0
ad34 ONLINE 0 0 0
cache
ad12 ONLINE 0 0 0
ad37 ONLINE 0 0 0
Here is the zdb dump :
prana
version=14
name='prana'
state=0
txg=3789517
pool_guid=4093564297936254749
hostname=''
vdev_tree
type='root'
id=0
guid=4093564297936254749
children[0]
type='raidz'
id=0
guid=2955456027802876323
nparity=1
metaslab_array=14
metaslab_shift=36
ashift=9
asize=7501485178880
is_log=0
children[0]
type='disk'
id=0
guid=14068763453858628066
path='/dev/ad16'
whole_disk=0
DTL=706
children[1]
type='disk'
id=1
guid=3644994118268583474
path='/dev/ad30'
whole_disk=0
DTL=4152
children[2]
type='disk'
id=2
guid=14192589917373989656
path='/dev/ad28'
whole_disk=0
DTL=93
children[3]
type='disk'
id=3
guid=12279545963786751752
path='/dev/ad18'
whole_disk=0
DTL=380
children[4]
type='disk'
id=4
guid=9980201723692421139
path='/dev/ad14'
whole_disk=0
DTL=647
children[1]
type='raidz'
id=1
guid=1078755695237588414
nparity=1
metaslab_array=175
metaslab_shift=36
ashift=9
asize=7501485178880
is_log=0
children[0]
type='disk'
id=0
guid=12900041001921590764
path='/dev/ada2'
whole_disk=0
DTL=4127
children[1]
type='disk'
id=1
guid=7067019390683734240
path='/dev/ad4'
whole_disk=0
DTL=198
children[2]
type='disk'
id=2
guid=783285185901703545
path='/dev/ad6'
whole_disk=0
DTL=197
children[3]
type='disk'
id=3
guid=9688838378677189049
path='/dev/ad8'
whole_disk=0
DTL=196
children[4]
type='replacing'
id=4
guid=500478404305589015
whole_disk=0
children[0]
type='disk'
id=0
guid=16391273719868046777
path='/dev/ada3/old'
whole_disk=0
not_present=1
DTL=195
children[1]
type='disk'
id=1
guid=17286942469715238412
path='/dev/ada3'
whole_disk=0
not_present=1
DTL=4146
children[2]
type='raidz'
id=2
guid=4090878701271390479
nparity=1
metaslab_array=164
metaslab_shift=36
ashift=9
asize=7501485178880
is_log=0
children[0]
type='disk'
id=0
guid=2581994749932752632
path='/dev/ada3'
whole_disk=0
DTL=394
children[1]
type='disk'
id=1
guid=3261576559815570039
path='/dev/ada1'
whole_disk=0
DTL=393
children[2]
type='disk'
id=2
guid=2403801851152895606
path='/dev/ada0'
whole_disk=0
DTL=4105
children[3]
type='disk'
id=3
guid=5795813053837736090
path='/dev/ad32'
whole_disk=0
DTL=391
children[4]
type='disk'
id=4
guid=4547118883658878725
path='/dev/ad34'
whole_disk=0
DTL=390
I now can't detach/remove/replace the following drive because "no valid
replicas" or because you "can't replace a replacing drive".
I gather the problem would be solved if I had a drive with the proper
ZDB information and GUID to fool the pool, but I am clueless as to how
to generate this information, and it doesn't seem from what the manpage
says, that zdb allows you to modify this information.
Either that, or find a way to remove these bogus devices, or have the
pool "forget" that it must replace a device that does not exist anymore,
with a device that does not exist anymore.
I would gladly welcome any clue as to how the ZDB metadata work and are
stored on the disk, as I can't find written specifications short of
probing the ZFS code itself.
I can provide any information required, such as the first 512K for each
drive (containing the ZDB copies).
Thanks in advance for any help.
--
Stephane LAPIE, EPITA SRS, Promo 2005
"Even when they have digital readouts, I can't understand them."
--MegaTokyo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20100824/237eaa13/signature.pgp
More information about the freebsd-fs
mailing list