Date: Tue, 17 Nov 2009 16:33:41 -0600 From: Robert Noland <rnoland@FreeBSD.org> To: Emil Smolenski <ambsd@raisa.eu.org> Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" Message-ID: <1258497221.2303.66.camel@balrog.2hip.net> In-Reply-To: <op.u3j6m8w5qvde5b@bolt.zol> References: <op.u3hw9wl0qvde5b@am-laptop.local.org> <1258390784.2303.42.camel@balrog.2hip.net> <op.u3h252qaqvde5b@bolt.zol> <op.u3j6m8w5qvde5b@bolt.zol>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2009-11-17 at 22:43 +0100, Emil Smolenski wrote: > On Mon, 16 Nov 2009 19:33:34 +0100, Emil Smolenski <ambsd@raisa.eu.org> > wrote: > > >> Matt's patch only effects raidz volumes. > > Oh, I see. Maybe there is similar bug in ZFS on single disk volumes > > also? > > >>> (is this procedure of updating zfsboot correct?) > >> This should be correct for updating the first stage bootstrap code. The > >> loader (boot/loader) is actually updated during installworld. > > > > I'll try full build/installworld tomorrow. > > It, unfortunately, didn't solve this issue. Should I file a PR? I would > like to help in debugging it (however my skills in low-level C aren't > strong enough to do it on my own). Ok, the first thing I would like to see is "zdb -uuu". I don't see an obvious issue with single disk reads. My own setup uses 2 x 1TB currently. Failing to read the MOS is basically the first read attempt from the pool, in fact it is the read that attempts to mount the pool. robert. -- Robert Noland <rnoland@FreeBSD.org> FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1258497221.2303.66.camel>