Kyle McDonald wrote:
Hi Darren,
More below...
Darren J Moffat wrote:
Tristan Ball wrote:
Obviously sending it deduped is more efficient in terms of bandwidth
and CPU time on the recv side, but it may also be more complicated to
achieve?
A stream can be deduped even if the on disk format
Kyle McDonald wrote:
Hi Darren,
More below...
Darren J Moffat wrote:
Tristan Ball wrote:
Obviously sending it deduped is more efficient in terms of bandwidth
and CPU time on the recv side, but it may also be more complicated
to achieve?
A stream can be deduped even if the on disk format i
Hi Darren,
More below...
Darren J Moffat wrote:
Tristan Ball wrote:
Obviously sending it deduped is more efficient in terms of bandwidth
and CPU time on the recv side, but it may also be more complicated to
achieve?
A stream can be deduped even if the on disk format isn't and vice versa.
Tristan Ball wrote:
I'm curious as to how send/recv intersects with dedupe... if I send/recv
a deduped filesystem, is the data sent it it's de-duped form, ie just
sent once, followed by the pointers for subsequent dupe data, or is the
the data sent in expanded form, with the recv side system
Tristan, there's another dedup system for "zfs send" in PSARC 2009/557. This
can be used independently of whether the in-pool data was deduped.
Case log: http://arc.opensolaris.org/caselog/PSARC/2009/557/
Discussion: http://www.opensolaris.org/jive/thread.jspa?threadID=115082
So I believe your
I'm curious as to how send/recv intersects with dedupe... if I send/recv
a deduped filesystem, is the data sent it it's de-duped form, ie just
sent once, followed by the pointers for subsequent dupe data, or is the
the data sent in expanded form, with the recv side system then having to
redo
