We have found the problem. The mountpoint property on the sender was at one time changed from the default, then later changed back to defaults using zfs set instead of zfs inherit. Therefore, zfs send included these local "non-default" properties in the stream, even though the local properties are effectively set at defaults. This caused the receiver to stop processing subsequent properties in the stream because the mountpoint isn't valid on the receiver.
I tested this theory with a spare zpool. First I used "zfs inherit mountpoint promise1/archive" to remove the "local" setting (which was exactly the same value as the default). This time the compression=gzip property was correctly received. It seems like a bug to me that one failed property in a stream prevents the rest from being applied. I should have used zfs inherit, but it would be best if zfs receive handled failures more gracefully, and attempted to set as many properties as possible. Thanks to Cindy and Tom for their help. Daniel On Wed, Apr 7, 2010 at 2:31 AM, Tom Erickson <thomas.erick...@oracle.com>wrote: > > 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. > > 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. >
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
