zfs recv panic
Kristof Provost
kristof at sigsegv.be
Tue May 16 18:53:30 UTC 2017
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
More information about the freebsd-current
mailing list