Daniel Bakken wrote:
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.
Yep, that's ZIO_COMPRESS_GZIP_6, the default 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.
Now I remember that 'zfs receive' used to give up after the first
property it failed to set. If I'm remembering correctly, then, in this
case, if the mountpoint was invalid on the receive side, 'zfs receive'
would not even try to set the remaining properties.
You could try 'zfs get mountpoint' (or 'zdb -vvv poolname > file' and
search the file for 'mountpoint') to see if that was set.
I'd like to try the dtrace debugging, but it would destroy the progress
I've made so far transferring the filesystem.
Maybe you could try receiving into a new pool that you can later throw away.
zpool create bogustestpool c0t0d0
zfs send -R promise1/arch...@daily.1 | zfs receive -vd bogustestpool
I'd try the following in the source dataset:
zfs inherit mountpoint promise1/archive
to clear the explicit mountpoint and prevent it from being included in
the send stream. Later set it back the way it was. (Soon there will be
an option to take care of that; see CR 6883722 want 'zfs recv -o
prop=value' to set initial property values of received dataset.) Then
see if you receive the compression property successfully.
Tom
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
