Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable"

On Mon, 2009-11-09 at 09:48 +0100, alteriks_at_gmail.com wrote:
> On Thursday 29 October 2009 11:36:38 Robert Noland wrote:
> > Ok, if you are getting this... It may be helpful if you can run "zdb
> > -uuu zroot", so I can see what is going on with the root block pointer.
> > I think you should be able to do that from fixit.  Also note that you
> > don't have the latest version of the loader if it is printing "lld",
> > though as long as all of the drives are detected it likely won't make a
> > difference.  The "can't read MOS" error is the first attempt to read
> > from the pool after probing all of the devices to sort out the
> > configuration.  Everything up to this point reads data directly from the
> > vdev labels on each drive, so this is the first time that it tries to
> > read from the pool.
> > 
> Sorry I forgot about this part.
> Here is zdb -uuu zroot
> Uberblock
> 
>         magic = 0000000000bab10c
>         version = 13
>         txg = 111
>         guid_sum = 14036990686815153767
>         timestamp = 1257636491 UTC = Sat Nov  7 23:28:11 2009
>         rootbp = [L0 DMU objset] 400L/200P DVA[0]=<0:110004a000:400> 
> DVA[1]=<0:40038400:400> DVA[2]=<0:1980041c00:400> fletcher4 lzjb LE contiguous 
> birth=111 fill=126 cksum=7e96f92e7:357c99e1eb9:b7d10db3a713:1ac2df05bd147a

Ok, that all looks correct for a raidz1.  The logical size is 1024 bytes
(400L) which is the uncompressed size of the data.  The physical size is
512 bytes (200P) which is one sector on disk and the allocated size is
1024 bytes (512 bytes + 512 bytes of parity).  For a raidz or mirror
pool, the vdev is always 0, which represents the pseudo vdev, but it
doesn't tell us for sure that all of the physical disks have been found.
We should be able to verify that all the disks are present by summing
the GUIDs.  I'll have a look at that, so that we can at least warn if
that is the case.  If all of the physical devices are accounted for,
then something is going wrong in the raidz read function, though I don't
understand why it isn't more prolific if that is the case.  i.e. why my
raidz2 test is working fine.

robert.

-- 
Robert Noland <rnoland_at_FreeBSD.org>
FreeBSD