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

On Thu, 2009-11-12 at 22:15 -0800, Matt Reimer wrote:
> 2009/11/12 Robert Noland <rnoland_at_freebsd.org>:
> > On Thu, 2009-11-12 at 16:54 -0800, Matt Reimer wrote:
> >> 2009/10/15 Radek Valášek <valin_at_buchlovice.org>:
> >> > Everything works fine for me, until I rewrite kernel/world after system
> >> > upgrade to latest one (releng_8). After this am I no longer able to boot
> >> > from zfs raidz1 pool with following messages:
> >> >
> >> >>/ ZFS: i/o error - all block copies unavailable
> >> > />/ ZFS: can't read MOS
> >> > />/ ZFS: unexpected object set type lld
> >> > />/ ZFS: unexpected object set type lld
> >> > />/
> >> > />/ FreeBSD/i386 boot
> >> > />/ Default: z:/boot/kernel/kernel
> >> > />/ boot:
> >> > />/ ZFS: unexpected object set type lld
> >> > />/
> >> > />/ FreeBSD/i386 boot
> >> > />/ Default: tank:/boot/kernel/kernel
> >> > />/ boot:
> >>
> >> Radek,
> >>
> >> Try the attached patch (sponsored by VPOP Technologies). I found an
> >> overflow in /sys/cddl/boot/zfs/zfssubr.c:vdev_raidz_read() that was
> >> causing my 6x1TB raidz2 array to fail to boot.
> ...
> >> The kernel source for the corresponding functionality is in
> >> /sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_raidz.c:vdev_raidz_map_alloc().
> >> There all these variables are uint64_t, but I think unnecessarily. I
> >> tried changing the boot loader's vdev_raidz_read() variables to all
> >> uint64_t but then gptzfsboot would reboot itself, likely due to a
> >> stack overflow. The attached patch just changes a few variables that,
> >> after a quick analysis, seemed likely to overflow.
> >>
> >> If this looks good, would someone commit it?
> >
> > ps_at_ grabbed it up already, but I may handle the MFC for him.  I have
> > some other minor fixups in my tree right now... like teaching printf to
> > handle %llx.  Thanks for finding this... It's been really frustrating
> > that I couldn't produce a failing system.
> 
> Is it possible for this patch to get into 8.0-RELEASE, or is it too
> late? I suppose it doesn't matter that much since the loader isn't
> built with LOADER_ZFS_SUPPORT by default anyway, so folks are going to
> have to compile it themselves.

I think we have missed the boat, but I'll talk to re_at_ and see if we can
get it in.

robert.

> Matt
-- 
Robert Noland <rnoland_at_FreeBSD.org>
FreeBSD