# [OmniOS-discuss] zfs recv assertion failed when scrubbing source pool

Dan McDonald danmcd at omniti.com
Fri Mar 4 15:54:09 UTC 2016

- Previous message: [OmniOS-discuss] zfs recv assertion failed when scrubbing source pool
- Next message: [OmniOS-discuss] RSF-1/ZFS panics node when offlining one iSCSI storage mirror
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    > On Mar 4, 2016, at 7:17 AM, Lauri Tirkkonen <lotheac at iki.fi> wrote:
    >
    > Because there is sensitive data involved, I'm reluctant to share either the
    > core or the stream, but would appreciate any cluebats. Thanks.

    The length in question arrives via a drr_payloadlen.  See zfs_receive_package(), line 2589 on illumos-gate:

    2585	/*
    2586	 * Read in the nvlist from the stream.
    2587	 */
    2588	if (drr->drr_payloadlen != 0) {
    2589		error = recv_read_nvlist(hdl, fd, drr->drr_payloadlen,
    2590		    &stream_nv, flags->byteswap, zc);
    2591		if (error) {
    2592			error = zfs_error(hdl, EZFS_BADSTREAM, errbuf);
    2593			goto out;
    2594		}
    2595	}

    Can you zstreamdump and see if any drr_payloadlen looks iffy?

    Also, are you sending this stream from a post-illumos-5027 (Large Block Size) box to a pre-illumos-5027 receiver?  A quick disassembly of recv_read() can tell you what it thinks SPA_MAXBLOCKSIZE is.  Otherwise, for some reason the drr_payloadlen of one of these payloads is WAY OFF for some reason.

    Hope this helps,
    Dan

- Previous message: [OmniOS-discuss] zfs recv assertion failed when scrubbing source pool
- Next message: [OmniOS-discuss] RSF-1/ZFS panics node when offlining one iSCSI storage mirror
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the OmniOS-discuss mailing list