Re: zfs recv panic

From: Kristof Provost <kristof_at_sigsegv.be>
Date: Wed, 17 May 2017 00:23:24 +0530
On 16 May 2017, at 19:58, Andriy Gapon wrote:
> On 16/05/2017 16:49, Kristof Provost wrote:
>> On 16 May 2017, at 15:41, Andriy Gapon wrote:
>>> On 10/05/2017 12:37, Kristof Provost wrote:
>>>> I have a reproducible panic on CURRENT (r318136) doing
>>>> (jupiter) # zfs send -R -v zroot/var_at_before-kernel-2017-04-26 | nc 
>>>> dual 1234
>>>> (dual) # nc -l 1234 | zfs recv -v -F tank/jupiter/var
>>>>
>>>> For clarity, the receiving machine is CURRENT r318136, the sending 
>>>> machine is
>>>> running a somewhat older CURRENT version.
>>>>
>>>> The receiving machine panics a few seconds in:
>>>>
>>>> receiving full stream of zroot/var_at_before-kernel-2017-04-03 into
>>>> tank/jupiter/var_at_before-kernel-2017-04-03
>>>> panic: solaris assert: dbuf_is_metadata(db) == arc_is_metadata(buf) 
>>>> (0x0 ==
>>>> 0x1), file: 
>>>> /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c,
>>>> line: 2007
>>>
>>> could you please try to revert commits related to the compressed 
>>> send and see if
>>> that helps?  I assume that the sending machine does not have (does 
>>> not use) the
>>> feature while the target machine is capable of the feature.
>>>
>>> The commits are: r317648 and r317414.  Mot that I really suspect 
>>> that change,
>>> but just to eliminate the possibility.
>>
>> Those commits appear to be the trigger.
>> I’ve not changed the sender, but with those reverted I don’t see 
>> the panic any
>> more.
>
> Thank you for testing.
> Do you still have the old kernel / module and the crash dump?
> It would interesting to poke around in frame 14.
>
>
This contains the kernel and crash files:
https://www.sigsegv.be/files/zfs_recv_kernel_crash.tar.bz2

I was running r318356 at the time of this panic.

Regards,
Kristof
Received on Tue May 16 2017 - 16:53:30 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC