Not quite brave enough to put dedup into prodiction here.
Concerned about the issues some folks have had when releasing large numbers of
blocks in one go.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
On Mar 19, 2010, at 1:28 PM, Richard Jahnel wrote:
They way we do this here is:
zfs snapshot voln...@snapnow
[i]#code to break on error and email not shown.[/i]
zfs send -i voln...@snapbefore voln...@snapnow | pigz -p4 -1 file
[i]#code to break on error and email not shown.[/i]
scp
On Mon, Mar 22, 2010 at 10:26 AM, Richard Elling
richard.ell...@gmail.comwrote:
NB. deduped streams should further reduce the snapshot size.
I haven't seen a lot of discussion on the list regarding send dedup, but I
understand it'll use the DDT if you have dedup enabled on your dataset.
What's
On 03/22/10 05:04 PM, Brandon High wrote:
On Mon, Mar 22, 2010 at 10:26 AM, Richard Elling
richard.ell...@gmail.com mailto:richard.ell...@gmail.com wrote:
NB. deduped streams should further reduce the snapshot size.
I haven't seen a lot of discussion on the list regarding send dedup,
On Thu, Mar 18, 2010 at 10:38:00PM -0700, Rob wrote:
Can a ZFS send stream become corrupt when piped between two hosts
across a WAN link using 'ssh'?
No. SSHv2 uses HMAC-MD5 and/or HMAC-SHA-1, depending on what gets
negotiated, for integrity protection. The chances of random on the wire
On Fri, Mar 19, 2010 at 12:38 PM, Rob slewb...@yahoo.com wrote:
Can a ZFS send stream become corrupt when piped between two hosts across a
WAN link using 'ssh'?
unless the end computers are bad (memory problems, etc.), then the
answer should be no. ssh has its own error detection method, and
On Fri, March 19, 2010 00:38, Rob wrote:
Can a ZFS send stream become corrupt when piped between two hosts across a
WAN link using 'ssh'?
For example a host in Australia sends a stream to a host in the UK as
follows:
# zfs send tank/f...@now | ssh host.uk receive tank/bar
In general,
On Fri, 19 Mar 2010, David Dyer-Bennet wrote:
However, these legacy mechanisms aren't guaranteed to give you the
less-than-one-wrong-bit-in-10^15 level of accuracy people tend to want for
enterprise backups today (or am I off a couple of orders of magnitude
there?). They were defined when
On Fri, March 19, 2010 09:49, Bob Friesenhahn wrote:
On Fri, 19 Mar 2010, David Dyer-Bennet wrote:
However, these legacy mechanisms aren't guaranteed to give you the
less-than-one-wrong-bit-in-10^15 level of accuracy people tend to want
for
enterprise backups today (or am I off a couple of
On Fri, 19 Mar 2010, David Dyer-Bennet wrote:
I don't think of stream crypto as inherently including validity checking,
though in practice I suppose it would always be a good idea.
This is obviously a vital and necessary function of ssh in order to
defend against man in the middle attacks.
They way we do this here is:
zfs snapshot voln...@snapnow
[i]#code to break on error and email not shown.[/i]
zfs send -i voln...@snapbefore voln...@snapnow | pigz -p4 -1 file
[i]#code to break on error and email not shown.[/i]
scp /dir/file u...@remote:/dir/file
[i]#code to break on error and
On 03/20/10 09:28 AM, Richard Jahnel wrote:
They way we do this here is:
zfs snapshot voln...@snapnow
[i]#code to break on error and email not shown.[/i]
zfs send -i voln...@snapbefore voln...@snapnow | pigz -p4 -1 file
[i]#code to break on error and email not shown.[/i]
scp /dir/file
no, but I'm slightly paranoid that way. ;)
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Can a ZFS send stream become corrupt when piped between two hosts across a WAN
link using 'ssh'?
For example a host in Australia sends a stream to a host in the UK as follows:
# zfs send tank/f...@now | ssh host.uk receive tank/bar
--
This message posted from opensolaris.org
14 matches
Mail list logo
