Maybe I should have posted the zdb -l output. Having seen another thread which
suggests that I might be looking at the most recent txg being damaged, I went
to get my pool's txg counter:
hydra# zdb -l /dev/dsk/c3t10d0s0 | grep txg
txg=10168474
txg=10168474
txg=6324561
txg=6324561
All of the disks are like this (indeed, the only thing that differs about their
zdb -l output is their own guids, as expected). Staring at reams of od -x
output, it appears that I have txgs 10168494 through 10168621 in L0 and L1. L2
and L3 appear to have not been updated in some time! L0 and L1 are both
"version=14" and have a hostname field.... L2 and L3 are both "version=3" and
do not. All four labels appear to describe the same array (guids and devices
and all). The uberblocks in L2 and L3 seem to contain txgs 6319346 through
6319473. That's uh... "funny".
A little bit of dtrace and time travel back to vdev.c as of snv_115 later, I
find that the immediate cause is that vdev_raidz_open is yielding an asize of
1280262012928 but that
when vdev_open called vdev_raidz_open, it thought the asize was 1280272498688.
(Thus vdev_open and vdev_root_open return EINVAL, and the import fails.) That
is, the array is actually one megabyte smaller than it thought... which works
out to 256K per disk, which is exactly the size of a label pair and might
explain why L2 and L3 are stale.
Help?
--
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
