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.
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?
-B
--
Brandon High : bh...@freaks.com
Suspicion Breeds Confidence
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
