Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Osvald Ivarsson <osvald <at> osvald.org>
Subject: Re: Unable to import pool: invalid vdev configuration
Newsgroups: gmane.os.solaris.opensolaris.zfs
Date: Saturday 3rd October 2009 15:46:07 UTC (over 7 years ago)
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
-- 
This message posted from opensolaris.org
 
CD: 4ms