Hi. We've got some test machines which amongst others has zpools in various sizes and placements scribbled all over the disks.
0. HP DL380G3, Solaris10u8, 2x16G disks; c1t0d0 & c1t1d0 1. Took a (non-emptied) disk, created a 2GB slice0 and a ~14GB (to the last cyl) slice7. 2. zpool create striclek c1t1d0s0 3. zdb -l /dev/rdsk/c1t1d0s0 shows 4 labels, each with the same guid and only c1t1d0s0 as vdev. All is well. 4. format, increase slice0 from 2G to 16G. remove slice7. label. 5. zdb -l /dev/rdsk/c1t1d0s0 shows 2 labels from the correct guid & c1t1d0s0, it also shows 2 labels from some old guid (from an rpool which was abandoned long ago) belonging to a mirror(c1t0d0s0,c1t1d0s0). c1t0d0s0 is current boot disk with other rpool and other guid. 6. zpool export striclek;zpool import shows guid from the "working pool", but that it's missing devices (although only lists c1t1d0s0 - ONLINE) 7. zpool import striclek doesn't work. zpool import theworkingguid doesn't work. If I resize the slice back to 2GB, all 4 labels shows the workingguid and import works again. Questions: * Why does 'zpool import' show the guid from label 0/1, but wants vdev conf as specified by label 2/3? * Is there no timestamp or such, so it would prefer label 0/1 as they are brand new and ignore label 2/3 which are waaay old. I can agree to being forced to scribble zeroes/junk all over the "slice7 space" which we're expanding to in step 4.. But stuff shouldn't fail this way IMO.. Maybe comparing timestamps and see that label 2/3 aren't so hot anymore and ignore them, or something.. zdb -l and zpool import dumps at: http://www.acc.umu.se/~stric/tmp/zdb-dump/ /Tomas -- Tomas Ögren, st...@acc.umu.se, http://www.acc.umu.se/~stric/ |- Student at Computing Science, University of Umeå `- Sysadmin at {cs,acc}.umu.se _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
