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