In the Thoughts on ZFS Pool Backup Strategies thread it was stated
that zfs send, sends uncompress data and uses the ARC.
If zfs send sends uncompress data which has already been compress
this is not very efficient, and it would be *nice* to see it send the
original compress data. (or an
On Fri, March 26, 2010 07:06, Edward Ned Harvey wrote:
In the Thoughts on ZFS Pool Backup Strategies thread it was stated
that zfs send, sends uncompress data and uses the ARC.
If zfs send sends uncompress data which has already been compress
this is not very efficient, and it would be
On Fri, March 26, 2010 09:46, David Dyer-Bennet wrote:
I don't know that it makes sense to. There are lots of existing filter
packages that do compression; so if you want compression, just put them in
your pipeline. That way you're not limited by what zfs send has
implemented, either. When
In the Thoughts on ZFS Pool Backup Strategies thread it was stated that zfs
send, sends uncompress data and uses the ARC.
If zfs send sends uncompress data which has already been compress this is not
very efficient, and it would be *nice* to see it send the original compress
data. (or an
On Mar 25, 2010, at 6:13 AM, Damon Atkins wrote:
In the Thoughts on ZFS Pool Backup Strategies thread it was stated that zfs
send, sends uncompress data and uses the ARC.
If zfs send sends uncompress data which has already been compress this is
not very efficient, and it would be *nice* to
Wither it is efficient or not to send the compressed or uncompressed
data depends on a lot of factors.
If the data is already in the ARC for some other reason then it is
likely much more efficient to use that because sending the compressed
blocks involves doing IO to disk. Reading the
On Thu, Mar 25, 2010 at 04:23:38PM +, Darren J Moffat wrote:
If the data is in the L2ARC that is still better than going out to
the main pool disks to get the compressed version.
advocate customer='devil'
Well, one could just compress it... If you'd otherwise put compression
in the ssh
