Harry Putnam writes:
> As you see the default Cipher was barely a minute faster than
> the arcfour over 28.7 GB of data.
>
> Absolutely NOT a diffinative test in any way but should at least show
> that on this network arcfour is likely to be no faster than the
> defaults in
Harry Putnam writes:
> As you see the default Cipher was barely a minute faster than
> the arcfour over 28.7 GB of data.
>
> Absolutely NOT a diffinative test in any way but should at least show
> that on this network arcfour is likely to be no faster than the
> defaults in
Geoff Nordli writes:
> Just a thought here, you may want to try a different ssh cipher. Give
> arcfour a try and see if that is fast enough for you.
>
> Geoff
I made an attempt to see about the various speeds available
with different Ciphers were like
I didn't use any solaris
On 3/28/2017 5:24 AM, Harry Putnam wrote:
> Timothy Coalson writes:
>
>> On Mon, Mar 27, 2017 at 9:44 PM, Harry Putnam wrote:
>>
>>> Geoff Nordli writes:
>>>
>>> [...]
>>>
Just a thought here, you may want to try a different ssh
On 2017-03-27 09:33 PM, Timothy Coalson wrote:
On Mon, Mar 27, 2017 at 9:44 PM, Harry Putnam wrote:
Geoff Nordli writes:
[...]
Just a thought here, you may want to try a different ssh cipher. Give
arcfour a try and see if that is fast enough for you.
Harry Putnam writes:
> I tried this at ~/.ssh/config on source host. The host named
> in the config is the destination host that is running the rsync cmd.
>
> Host g1 <= name of linux host
> HostName g1.local.lan <=same linux host
> Ciphers arcfour
Nevermind
Geoff Nordli writes:
> On 2017-03-27 07:44 PM, Harry Putnam wrote:
>> Geoff Nordli writes:
>>
>> [...]
>>
>>> Just a thought here, you may want to try a different ssh cipher. Give
>>> arcfour a try and see if that is fast enough for you.
>>>
>> Can that be done
Harry Putnam writes:
> I think what Timothy C has in mind is dropping mbuffer/tamp and using
> ssh for the whole thing
>
> zfs send p/fs@now | ssh RECV_HOST zfs recv p/fs
OOps that should have read ...
I think what Geoff N has in mind [...]
Timothy Coalson writes:
> On Mon, Mar 27, 2017 at 9:44 PM, Harry Putnam wrote:
>
>> Geoff Nordli writes:
>>
>> [...]
>>
>> >
>> > Just a thought here, you may want to try a different ssh cipher. Give
>> > arcfour a try and see if that is
On 2017-03-27 07:44 PM, Harry Putnam wrote:
Geoff Nordli writes:
[...]
Just a thought here, you may want to try a different ssh cipher. Give
arcfour a try and see if that is fast enough for you.
Can that be done on ssh command line or must be done in ssh_config?
On Mon, Mar 27, 2017 at 9:44 PM, Harry Putnam wrote:
> Geoff Nordli writes:
>
> [...]
>
> >
> > Just a thought here, you may want to try a different ssh cipher. Give
> > arcfour a try and see if that is fast enough for you.
> >
>
> Can that be done on ssh
jason matthews writes:
Sorry that I slaughtered your nifty commands so bad. I haven't been
able to get copy paste working on the vm that is the target and so
have been torturing things with my poor typing.
This time I scpped your message across to both hosts so no bunky
Geoff Nordli writes:
[...]
>
> Just a thought here, you may want to try a different ssh cipher. Give
> arcfour a try and see if that is fast enough for you.
>
Can that be done on ssh command line or must be done in ssh_config?
___
On 3/27/17 10:18 AM, Geoff Nordli wrote:
On 2017
,
| sender:
| zfs send tank/dana@snap1 | tamp | mbuffer -s 128k -m 1000m -O
| target_host:31337
|
| receiver:
| mbuffer -s 128k -m 1999m -I 31337 | tamp -d | zfs recv -vFd newtank
`
My rendition:
zfs send p0/vb/vm@170326_1
On 2017-03-27 01:40 AM, Harry Putnam wrote:
Trying to learn how to use mbuffer and tamp to do zfs send/receive
rather than ssh which is pretty slow even on my home gigabit lan at
home where there is very little traffic.
So far using ready made examples from posters on this group or a few I
James Carlson via openindiana-discuss
writes:
> On 03/27/17 04:40, Harry Putnam wrote:
>> My rendition:
>>
>> zfs send p0/vb/vm@170326_1 |tamp|mbuffer -s 128k -m1000m -0
>> recv-host:31337 | mbuffer -s 128k -m 1999m -I 31337 |tamp -d |
>> zfs recv -vF
On 03/27/17 04:40, Harry Putnam wrote:
> My rendition:
>
> zfs send p0/vb/vm@170326_1 |tamp|mbuffer -s 128k -m1000m -0
> recv-host:31337 | mbuffer -s 128k -m 1999m -I 31337 |tamp -d |
> zfs recv -vF p0/vb/vm
That makes no sense at all. The mbuffer utility doesn't produce usable
output on stdout
Trying to learn how to use mbuffer and tamp to do zfs send/receive
rather than ssh which is pretty slow even on my home gigabit lan at
home where there is very little traffic.
So far using ready made examples from posters on this group or a few I
found online I've constantly run into `connection
18 matches
Mail list logo