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

[Matt Reimer]

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.

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?

Matt