Panic in zfs_blkptr_verify()

[Xin Li]

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.

One thing worth trying is to set vfs.zfs.recover=1 from loader, and
import the pool read-only.  If this could succeed, you can migrate the
as much data as possible out of the pool.  You may also want to try
zpool import -F (and -F -X if -F didn't work) to see if discarding a few
latest txgs would be helpful.

> I've tried setting dumpon prior to this point (and I can see that
> dumpdev is set) but I don't get a crashdump.  Since this is my primary

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.

Cheers,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20150829/1f566af4/attachment.bin>