Here is the info from zstreamdump -v on the sending side:

BEGIN record
        hdrtype = 2
        features = 0
        magic = 2f5bacbac
        creation_time = 0
        type = 0
        flags = 0x0
        toguid = 0
        fromguid = 0
        toname = promise1/arch...@daily.1

nvlist version: 0
        tosnap = daily.1
        fss = (embedded nvlist)
        nvlist version: 0
                0xcfde021e56c8fc = (embedded nvlist)
                nvlist version: 0
                        name = promise1/archive
                        parentfromsnap = 0x0
                        props = (embedded nvlist)
                        nvlist version: 0
                                mountpoint = /promise1/archive
                                compression = 0xa
                                dedup = 0x2
                        (end props)

I assume that compression = 0xa means gzip. I wonder if the dedup property
is causing the receiver (build 111b)  to disregard all other properties,
since the receiver doesn't support dedup. Dedup was enabled in the past on
the sending filesystem, but is now disabled for reasons of sanity.

I'd like to try the dtrace debugging, but it would destroy the progress I've
made so far transferring the filesystem.

Thanks,

Daniel

On Wed, Apr 7, 2010 at 12:52 AM, Tom Erickson <thomas.erick...@oracle.com>wrote:

>
> The advice regarding received vs local properties definitely does not
> apply. You could still confirm the presence of the compression property in
> the send stream with zstreamdump, since the send side is running build 129.
> To debug the receive side I might dtrace the zap_update() function with the
> fbt provider, something like
>
> zfs send -R promise1/arch...@daily.1 | dtrace -c 'zfs receive -vd sas' \
> -n 'fbt::zap_update:entry / stringof(args[2]) == "compression" ||      \
> stringof(args[2]) == "compression$recvd" / { self->trace = 1; }'  \
> -n 'fbt::zap_update:return / self->trace / { trace(args[1]); \
> self->trace = 0; }'
>
> and look for non-zero return values.
>
> I'd also redirect 'zdb -vvv poolname' to a file and search it for
> "compression" to check the value in the ZAP.
>
> I assume you have permission to set the compression property on the receive
> side, but I'd check anyway.
>
> Tom
>
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to