From owner-freebsd-fs@FreeBSD.ORG Sat Sep 10 09:23:09 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C591D106566B for ; Sat, 10 Sep 2011 09:23:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1CBDC8FC0A for ; Sat, 10 Sep 2011 09:23:08 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA12646; Sat, 10 Sep 2011 12:23:04 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1R2JmC-000Ey8-Fp; Sat, 10 Sep 2011 12:23:04 +0300 Message-ID: <4E6B2C78.80102@FreeBSD.org> Date: Sat, 10 Sep 2011 12:23:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110907 Thunderbird/6.0.2 MIME-Version: 1.0 To: Peter Jeremy 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> In-Reply-To: <20110909051357.GA58043@server.vk2pj.dyndns.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS: i/o error - all block copies unavailable after upgrading to r225312 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Sep 2011 09:23:09 -0000 on 09/09/2011 08:13 Peter Jeremy said the following: > On 2011-Sep-08 09:07:06 +0300, Andriy Gapon 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 > 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