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

On Thu, 2009-11-12 at 16:54 -0800, Matt Reimer wrote:
> 2009/10/15 Radek Valášek <valin_at_buchlovice.org>:
> > Hi,
> >
> > I want to ask if there is something new in adding support to
> > gptzfsboot/zfsboot for reading gang-blocks?
> >
> > From Sun's docs:
> >
> > Gang blocks
> >
> > When there is not enough contiguous space to write a complete block, the ZIO
> > pipeline will break the I/O up into smaller 'gang blocks' which can later be
> > assembled transparently to appear as complete blocks.
> >
> > 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.
> 
> Apply the patch, build everything in /sys/boot, and then make sure you
> update both gptzfsboot and /boot/loader.
> 
> Robert, I'm guessing you couldn't replicate this because your array
> was small enough not to result in block numbers overflowing an int.

This is likely, all of my raidz tests were with vnode backed 1GB memory
disks.  So my largest configuration was a 6 x 1GB raidz2.

> 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.

robert.

> Matt
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
-- 
Robert Noland <rnoland_at_FreeBSD.org>
FreeBSD