Panic in zfs_blkptr_verify()

Peter Jeremy peter at rulingia.com
Sun Aug 30 18:57:25 UTC 2015


On 2015-Aug-29 03:02:31 -0700, Xin Li <delphij at delphij.net> wrote:
>On 8/28/15 23:27, Peter Jeremy wrote:
>> I'm trying to upgrade my main (amd64) server from 10-stable r276177 to
>> r287251 but the new kernel consistently panics:
>> 
>> Unfortunately, I'm not sure how to resolve this.  zfs_blkptr_verify() was
>> MFH in r277582 so the checks don't exist in my old kernel.  This means it
>> could be a problem with one of my pools, rather than a software bug.  But
>> there's no information in the panic that would let me identify where the
>> dodgy offset was found other than it's DVA 0 of some undefined blkptr_t.
>
>Unfortunately, I have to say that the pool may be beyond repair, and you
>may have to try importing it only and recreate the pool, or destroy it
>and restore from a backup.

Which pool?  I have two active pools, both of which are functioning
happily with a r276177 kernel.  A scrub of both reports no errors.

>That's probably not very useful because the panic is an assertion that
>we know the block pointer is bad, and from the backtrace, it looks like
>it was the toplevel dataset.

I gathered that the panic was early during pool opening/initialisation.
Is this part of the pool "tasting" and being triggered by random
junk in a non-ZFS dink partition?
Is it possible that 

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20150831/9a6df288/attachment.bin>


More information about the freebsd-fs mailing list