Date: Thu, 12 Nov 2009 22:15:07 -0800 From: Matt Reimer <mattjreimer@gmail.com> To: Robert Noland <rnoland@freebsd.org> Cc: freebsd-fs@freebsd.org, =?ISO-8859-2?Q?Radek_Val=E1=B9ek?= <valin@buchlovice.org>, freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" Message-ID: <f383264b0911122215h61d4d54as2d9511b6896a125f@mail.gmail.com> In-Reply-To: <1258087983.2303.23.camel@balrog.2hip.net> References: <4AD710D6.70404@buchlovice.org> <f383264b0911121654g3d15690eq4e6c92355e5368b6@mail.gmail.com> <1258087983.2303.23.camel@balrog.2hip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/11/12 Robert Noland <rnoland@freebsd.org>: > On Thu, 2009-11-12 at 16:54 -0800, Matt Reimer wrote: >> 2009/10/15 Radek Val=E1=B9ek <valin@buchlovice.org>: >> > Everything works fine for me, until I rewrite kernel/world after syste= m >> > upgrade to latest one (releng_8). After this am I no longer able to bo= ot >> > 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@ grabbed it up already, but I may handle the MFC for him. =A0I have > some other minor fixups in my tree right now... like teaching printf to > handle %llx. =A0Thanks 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. Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f383264b0911122215h61d4d54as2d9511b6896a125f>