Brandon High wrote:
I'm playing around with snv_128 on one of my systems, and trying to see what kinda of benefits enabling dedup will give me.The standard practice for reprocessing data that's already stored to add compression and now dedup seems to be a send / receive pipe similar to: zfs send -R <old fs>@snap | zfs recv -d <new fs> However, according to the man page, "The current values of properties [..] are set when the stream is received." With dedup, this isn't an issue because the property doesn't exist on the source fs so it can be inherited. For properties like sharesmb, it appears to be more awkward. The options seem to be either set up the target pool with the correct properties, then zfs send the earliest snapshot, then all others with 'zfs send -I', or disable the property on the source, then use 'zfs send -R'. The first option is a very manual process, since it doesn't work recursively on the pool. The second option isn't acceptable, since it'll interrupt service on the source.
Well, changing the "compression" property doesn't really interrupt service, but I can understand not wanting to have even a few blocks with the "wrong" setting on the source side. It does seem like a reasonable workaround, though.
Am I missing something? Is there a way to override the value of a property when sending, or to ignore it on the receiving side?
Not currently, but this is RFE 6883722 "want 'zfs recv -o prop=value' to set initial property values of received dataset".
--matt _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
