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 : bhigh at freaks.com
Suspicion Breeds Confidence
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
On Thu, Dec 10, 2009 at 2:15 PM, Tom Erickson <tom.erickson at sun.com> wrote:> After upgrading your pool on the receive side and doing ''zfs receive'' > once to initialize the new behavior, you can thereafter set a property > locally and it will not be overwritten by ''zfs receive''.Maybe I don''t understand what you mean, but I tried: # zfs send -R tank/export/home at now | ssh host2 zfs receive -vud -F tank which created a new filesystem as expected. I looked for a property that was had the source "received" and changed it, then tried the same send: # zfs send -R tank/export/home at zfs-auto-snap:hourly-2009-12-10-12:00 | ssh host2 zfs receive -vud -F tank cannot receive new filesystem stream: destination has snapshots (eg. tank/export/home at zfs-auto-snap:hourly-2009-12-09-18:00) must destroy them to overwrite it Of course, I can do zfs send -I with appropriate snapshots to update to a more current snapshot. But what if the source pool had a "bad" setting on it, such as changing the checksum type from fletcher2 to sha256? The fix recommended was a send|receive, as with the dedup=fletcher4,verify problem. Wouldn''t the initial send -R cause all / most of the data to be written with the source''s checksum method, or are some properties not set or always inherited on the receiving side? -B -- Brandon High : bhigh at freaks.com If violence doesn''t solve your problem, you''re not using enough of it.
On Thu, Dec 10, 2009 at 2:53 PM, Matthew Ahrens <Matthew.Ahrens at sun.com> wrote:> 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"I was thinking of sharesmb or sharenfs settings when I wrote that. Toggling them for the send would interrupt any clients trying to use the resource. Obviously disabling compression or dedup on the source doesn''t interrupt service -B -- Brandon High : bhigh at freaks.com For sale: One moral compass, never used.
Brandon High <bhigh at freaks.com> writes:> Matthew Ahrens <Matthew.Ahrens at sun.com> wrote: >> 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" > > I was thinking of sharesmb or sharenfs settings when I wrote that. > Toggling them for the send would interrupt any clients trying to use > the resource. Obviously disabling compression or dedup on the source > doesn''t interrupt serviceyou can avoid the problem by making sure the target filesystem isn''t mounted, i.e., by setting canmount=noauto on the source. it''s a bit ugly, since you''ll get an outage if the source server reboots before you set it back. -- Kjetil T. Homme Redpill Linpro AS - Changing the game
Kjetil Torgrim Homme wrote:> Brandon High <bhigh at freaks.com> writes: > >> Matthew Ahrens <Matthew.Ahrens at sun.com> wrote: >>> 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" >> I was thinking of sharesmb or sharenfs settings when I wrote that. >> Toggling them for the send would interrupt any clients trying to use >> the resource. Obviously disabling compression or dedup on the source >> doesn''t interrupt service > > you can avoid the problem by making sure the target filesystem isn''t > mounted, i.e., by setting canmount=noauto on the source. it''s a bit > ugly, since you''ll get an outage if the source server reboots before you > set it back.Or use the -u argument to ''zfs recv'': -u File system that is associated with the received stream is not mounted. -- Darren J Moffat
On Thu, Dec 10, 2009 at 5:18 PM, Tom Erickson <tom.erickson at sun.com> wrote:> That''s what I meant: If you ''zfs set'' a property on a dataset that you > plan to update with ''zfs receive'', then receiving from ''zfs send -Ri'' or > ''zfs send -RI'' will not overwrite the property on that existing dataset.Thanks for the additional clarification. I''ve gone through and audited the properties on the pool to ensure that settings are set at the highest level and inherited to child filesystems. Hopefully that will lessen the amount of tweaking that needs to be done later. -B -- Brandon High : bhigh at freaks.com