ZFS: i/o error - all block copies unavailable after upgrading to r225312

Andriy Gapon avg at FreeBSD.org
Sat Sep 10 09:23:09 UTC 2011


on 09/09/2011 08:13 Peter Jeremy said the following:
> On 2011-Sep-08 09:07:06 +0300, Andriy Gapon <avg at 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 at 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


More information about the freebsd-fs mailing list