Hi Osvald,
Can you comment on how the disks shrank or how the labeling on these
disks changed?
We would like to track the issues that causes the hardware underneath
a live pool to change so that we can figure out how to prevent pool
failures in the future.
Thanks,
Cindy
On 10/03/09 09:46, Osvald Ivarsson wrote:
I managed to solve this problem thanks to much help from Victor Latushkin.
Anyways, the problem is related to the following bug:
Bug ID 6753869
Synopsis labeling/shrinking a disk in raid-z vdev makes pool
un-importable
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6753869
Somehow my c14d0 disk was now a bit too small...
The following is from prtvtoc:
c14d0
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 4 00 256 1953503455 1953503710
8 11 00 1953503711 16384 1953520094
c14d1
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 4 00 256 1953508495 1953508750
8 11 00 1953508751 16384 1953525134
c15d0
* /dev/dsk/c15d0 partition map
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 4 00 256 1953508495 1953508750
8 11 00 1953508751 16384 1953525134
Victor wrote:
--------------------
For c14d0 we have 1953503455 blocks in slice 0, so if we divide it by 512 we'll
get number of 256KB blocks that can fit there, so it is 3815436.435546875 or
3815436 whole 256KB blocks
For c14t1 and c15d0 we have 1953508495, so it is 3815446.279296875 or 3815446
whole 256KB blocks.
We see that s0 on c14d0 is ten 256KB blocks smaller than other two.
Let's now determine how big s0 ZFS expects to have. We have asize for the raidz
in the label - it is 3000574672896. It is equal to the asize of the smallest
device multiplied by 3, so it should be divisible by 3 without remainder, and
it is:
3000574672896 / 3 = 1000191557632
So asize of the smallest device is 1000191557632 bytes or 3815428 blocks of
256KB. But we need to factor in ZFS front and back labels and reserved are in
the front between front labels and allocatabale area. Front labels a 0.5MB,
reserved area in the front is 3.5MB, this gives us 16 blocks of 256KB, plus two
labels in the back are 2 blocks of 256KB, so in total we have 18 additional
blocks and thus we arrive at required slice of s0 to be 3815446 blocks.
This is exactly size of c14d1 and c15d0, and c14d0 is different (too small)
You can use attached dtrace script to verify this calculations.
format -e to change size of slice 8 (or remove it altogether), and then
increase size of s0 so it is big enough to accommodate 3815446 blocks of 256KB
You can always try another option - remove c14d0 (physically or logically with
cfgadm -c unconfigure or just by removing symlink for c14d0s0 from /dev/dsk and
/dev/rdsk) and try to say 'zpool import' to see if it would be happy to import
pool in the degraded state
--------------------
So I tried to remove c14d0 by removing the symlinks, but that didn't change anything. So
I decided to use "format -e" to remove the slice 8 and increase s0, and that
actually worked! Now my pool imported without problems! Removing the disk would've worked
too.
Many thanks to Victor!
/Osvald Ivarsson
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
