Date: Sat, 10 Sep 2011 12:23:04 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Peter Jeremy <peterjeremy@acm.org> Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS: i/o error - all block copies unavailable after upgrading to r225312 Message-ID: <4E6B2C78.80102@FreeBSD.org> In-Reply-To: <20110909051357.GA58043@server.vk2pj.dyndns.org> References: <20110901223646.14b8aae8@o2.pl> <4E60DBBD.1040703@FreeBSD.org> <4E679D3D.1000007@FreeBSD.org> <20110908055016.GB28874@server.vk2pj.dyndns.org> <4E685B8A.604@FreeBSD.org> <20110909051357.GA58043@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 09/09/2011 08:13 Peter Jeremy said the following: > On 2011-Sep-08 09:07:06 +0300, Andriy Gapon <avg@FreeBSD.org> wrote: >> on 08/09/2011 08:50 Peter Jeremy said the following: >>> Since the problem isn't consistent (it can appear on some files but not >>> others), I modified zfstest to take a pathname, rather than have the >>> pathname hard-coded. >> >> I would appreciate your sharing back this enhancement. Thanks for >> testing! > > See attached. The first argument is a pathname to open and the remaining > arguments specify the pool as before. Note that I commented out the > spa_all_status() so I could easily cmp(1) the output with the file read via > the filesystem. Thank you. > On 2011-Sep-08 15:50:16 +1000, Peter Jeremy <peter@server.vk2pj.dyndns.org> > wrote: >> This was tested on an 8-STABLE system at r225392. I've built new >> bootblocks but not tested them yet - I will do that tomorrow. > > Unfortunately, the resultant gptzfsboot causes a "BTX Halted" problem (see > http://i.imgur.com/CuTut.jpg - apologies for the quality). Based on cs:eip > and ss:esp, it looks like it just goes off into the weeds. Not an expert on BTX dumps, so can't tell anything from it. But see below. > I've tried building it on two different systems (including a full > buildworld in case just running "make clean && make" in /usr/src/sys/boot > was insufficient) and get the same binary. An unpatched gptzfsboot from > r225392 works. I rather exceeded the time I should have invested in the > problem and so have gone ahead with a zpool rebuild to get rid of the > problematic gang-blocks. I understand your situation. Good thing is that I've been able to reproduce what looks like the same issue. I should have used myself the same C flags for zfstest as those that are used for "real" (gpt)zfsboot compilation and I should have advised those same flags to the testers like you and Sebastian. Currently the problem looks like a miscompilation by GCC that was triggered by my change. Sigh. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E6B2C78.80102>