Re: [zfs-discuss] send/recv over ssh
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Brent Jones Problem with mbuffer, if you do scripted send/receives, you'd have to pre-start an Mbuffer session on the receiving end somehow. SSH is always running on the receiving end, so no issues there. Could you use ssh to start the mbuffer session? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/recv over ssh
On Thu, May 20, 2010 19:44, Freddie Cash wrote: And you can always patch OpenSSH with HPN, thus enabling the NONE cipher, which disable encryption for the data transfer (authentication is always encrypted). And twiddle the internal buffers that OpenSSH uses to improve transfer rates, especially on 100 Mbps or faster links. Ah! I've been wanting that for YEARS. Very glad to hear somebody has done it. With the common use of SSH for for moving bulk data (under rsync as well), this is a really useful idea. Of course one should think about where one is moving one's data unencrypted; but the precise cases where the performance hit of encryption will show are the safe ones, such as between my desktop and server which are plugged into the same switch; no data would leave that small LAN segment. -- David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/recv over ssh
On Fri, May 21, 2010 at 7:12 AM, David Dyer-Bennet d...@dd-b.net wrote: On Thu, May 20, 2010 19:44, Freddie Cash wrote: And you can always patch OpenSSH with HPN, thus enabling the NONE cipher, which disable encryption for the data transfer (authentication is always encrypted). And twiddle the internal buffers that OpenSSH uses to improve transfer rates, especially on 100 Mbps or faster links. Ah! I've been wanting that for YEARS. Very glad to hear somebody has done it. ssh-1 has had the 'none' cipher from day one, though it looks like openssh has removed it at some point. Fixing the buffers seems to be a nice tweak though. With the common use of SSH for for moving bulk data (under rsync as well), this is a really useful idea. Of course one should think about where one I think there's a certain assumption that using ssh = safe, and by enabling a none cipher you break that assumption. All of us know better, but less experienced admins may not. -B -- Brandon High : bh...@freaks.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/recv over ssh
On Fri, May 21, 2010 at 10:59 AM, Brandon High bh...@freaks.com wrote: On Fri, May 21, 2010 at 7:12 AM, David Dyer-Bennet d...@dd-b.net wrote: On Thu, May 20, 2010 19:44, Freddie Cash wrote: And you can always patch OpenSSH with HPN, thus enabling the NONE cipher, which disable encryption for the data transfer (authentication is always encrypted). And twiddle the internal buffers that OpenSSH uses to improve transfer rates, especially on 100 Mbps or faster links. Ah! I've been wanting that for YEARS. Very glad to hear somebody has done it. ssh-1 has had the 'none' cipher from day one, though it looks like openssh has removed it at some point. Correct. It was available in early OpenSSH version, but then removed as it could compromise security. And the OpenSSH devs continue to reject any patches that re-enable the none cipher for this reason. Fixing the buffers seems to be a nice tweak though. Yes, this really makes a difference. We were initially bottlenecked by SSH (100-200 Mbps) for our rsync connections (gigabit fibre between buildings) between two FreeBSD servers (low CPU use, medium drive I/O). Bumping the buffers to 16384 on each side increased it to over 500 Mbps (now limited by CPU). We've since dropped it to 4096, as we have a lot of non-HPN-enabled remote sites we need to rysnc from, and anything over 4096 causes the connection to drop (remote end can't keep up). With the common use of SSH for for moving bulk data (under rsync as well), this is a really useful idea. Of course one should think about where one I think there's a certain assumption that using ssh = safe, and by enabling a none cipher you break that assumption. All of us know better, but less experienced admins may not. That's the gist of the OpenSSH devs' reasoning for rejecting the HPN patches everytime they are submitted. :) -- Freddie Cash fjwc...@gmail.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/recv over ssh
On Fri, May 21, 2010 12:59, Brandon High wrote: On Fri, May 21, 2010 at 7:12 AM, David Dyer-Bennet d...@dd-b.net wrote: On Thu, May 20, 2010 19:44, Freddie Cash wrote: And you can always patch OpenSSH with HPN, thus enabling the NONE cipher, which disable encryption for the data transfer (authentication is always encrypted). And twiddle the internal buffers that OpenSSH uses to improve transfer rates, especially on 100 Mbps or faster links. Ah! I've been wanting that for YEARS. Very glad to hear somebody has done it. ssh-1 has had the 'none' cipher from day one, though it looks like openssh has removed it at some point. Fixing the buffers seems to be a nice tweak though. I thought I remembered a none cipher, but couldn't find it the other year and decided I must have been wrong. I did use ssh-1, so maybe I really WAS remembering after all. With the common use of SSH for for moving bulk data (under rsync as well), this is a really useful idea. Of course one should think about where one I think there's a certain assumption that using ssh = safe, and by enabling a none cipher you break that assumption. All of us know better, but less experienced admins may not. Seems a high price to pay to try to protect idiots from being idiots. Anybody who doesn't understand that encryption = none means it's not encrypted and hence not safe isn't safe as an admin anyway. -- David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/recv over ssh
On Fri, May 21, 2010 at 11:28 AM, David Dyer-Bennet d...@dd-b.net wrote:
I thought I remembered a none cipher, but couldn't find it the other
year and decided I must have been wrong. I did use ssh-1, so maybe I
really WAS remembering after all.
It may have been in ssh2 as well, or at least the commercial version
.. I thought it used to be a compile time option for openssh too.
Seems a high price to pay to try to protect idiots from being idiots.
Anybody who doesn't understand that encryption = none means it's not
encrypted and hence not safe isn't safe as an admin anyway.
Well, it won't expose your passwords since the key exchange it still
encrypted ... That's good, right?
Circling back to the original topic, you can use ssh to start up
mbuffer on the remote side, then start the send. Something like:
#!/bin/bash
ssh -f r...@${recv_host} mbuffer -q -I ${SEND_HOST}:1234 | zfs recv
puddle/tank
sleep 1
zfs send -R tank/foo/bar | mbuffer -O ${RECV_HOST}:1234
When I was moving datasets between servers, I was on the console of
both, so manually starting the send/recv was not a problem.
I've tried doing it with netcat rather than mbuffer but it was
painfully slow, probably due to network buffers. ncat (from the nmap
devs) may be a suitable alternative, and can support ssl and
certificate based auth.
-B
--
Brandon High : bh...@freaks.com
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/recv over ssh
I seem to be getting decent speed with arcfour (this was what i was using to
begin with)
Thanks for all the helpthis honestly was just me being stupid...looking
back on yesterday, i can't even remember what i was doing wrong nowi was
REALLY tired when i asked this question.
On Fri, May 21, 2010 at 2:43 PM, Brandon High bh...@freaks.com wrote:
On Fri, May 21, 2010 at 11:28 AM, David Dyer-Bennet d...@dd-b.net wrote:
I thought I remembered a none cipher, but couldn't find it the other
year and decided I must have been wrong. I did use ssh-1, so maybe I
really WAS remembering after all.
It may have been in ssh2 as well, or at least the commercial version
.. I thought it used to be a compile time option for openssh too.
Seems a high price to pay to try to protect idiots from being idiots.
Anybody who doesn't understand that encryption = none means it's not
encrypted and hence not safe isn't safe as an admin anyway.
Well, it won't expose your passwords since the key exchange it still
encrypted ... That's good, right?
Circling back to the original topic, you can use ssh to start up
mbuffer on the remote side, then start the send. Something like:
#!/bin/bash
ssh -f r...@${recv_host} mbuffer -q -I ${SEND_HOST}:1234 | zfs recv
puddle/tank
sleep 1
zfs send -R tank/foo/bar | mbuffer -O ${RECV_HOST}:1234
When I was moving datasets between servers, I was on the console of
both, so manually starting the send/recv was not a problem.
I've tried doing it with netcat rather than mbuffer but it was
painfully slow, probably due to network buffers. ncat (from the nmap
devs) may be a suitable alternative, and can support ssl and
certificate based auth.
-B
--
Brandon High : bh...@freaks.com
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] send/recv over ssh
I know i'm probably doing something REALLY stupid.but for some reason i can't get send/recv to work over ssh. I just built a new media server and i'd like to move a few filesystem from my old server to my new server but for some reason i keep getting strange errors... At first i'd see something like this: pfexec: can't get real path of ``/usr/bin/zfs'' or something like this: zfs: Command not found from google it's mentioned something about nfs but i've disabled autofs.. anyways, thanks for any helpi know it is just something stupid but my brain just isn't working... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/recv over ssh
also, i forgot to say: one server is b133, the new one is b134 On Thu, May 20, 2010 at 4:23 PM, Thomas Burgess wonsl...@gmail.com wrote: I know i'm probably doing something REALLY stupid.but for some reason i can't get send/recv to work over ssh. I just built a new media server and i'd like to move a few filesystem from my old server to my new server but for some reason i keep getting strange errors... At first i'd see something like this: pfexec: can't get real path of ``/usr/bin/zfs'' or something like this: zfs: Command not found from google it's mentioned something about nfs but i've disabled autofs.. anyways, thanks for any helpi know it is just something stupid but my brain just isn't working... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/recv over ssh
On Thu, May 20, 2010 at 04:23:49PM -0400, Thomas Burgess wrote: I know i'm probably doing something REALLY stupid.but for some reason i can't get send/recv to work over ssh. I just built a new media server and i'd like to move a few filesystem from my old server to my new server but for some reason i keep getting strange errors... At first i'd see something like this: pfexec: can't get real path of ``/usr/bin/zfs'' or something like this: zfs: Command not found Add /usr/sbin to your PATH or use /usr/sbin/zfs as the full path of the zfs(1M) command. Nico -- ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/recv over ssh
On Thu, May 20, 2010 at 1:23 PM, Thomas Burgess wonsl...@gmail.com wrote: I know i'm probably doing something REALLY stupid.but for some reason i can't get send/recv to work over ssh. I just built a new media server and Unless you need to have the send to be encrypted, ssh is going to slow you down a lot. I've used mbuffer when doing sends on the same network, it's worked well. -B -- Brandon High : bh...@freaks.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/recv over ssh
On Thu, May 20, 2010 at 3:42 PM, Brandon High bh...@freaks.com wrote: On Thu, May 20, 2010 at 1:23 PM, Thomas Burgess wonsl...@gmail.com wrote: I know i'm probably doing something REALLY stupid.but for some reason i can't get send/recv to work over ssh. I just built a new media server and Unless you need to have the send to be encrypted, ssh is going to slow you down a lot. I've used mbuffer when doing sends on the same network, it's worked well. -B -- Brandon High : bh...@freaks.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss Problem with mbuffer, if you do scripted send/receives, you'd have to pre-start an Mbuffer session on the receiving end somehow. SSH is always running on the receiving end, so no issues there. -- Brent Jones br...@servuhome.net ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/recv over ssh
On Thu, May 20, 2010 at 4:40 PM, Brent Jones br...@servuhome.net wrote: On Thu, May 20, 2010 at 3:42 PM, Brandon High bh...@freaks.com wrote: On Thu, May 20, 2010 at 1:23 PM, Thomas Burgess wonsl...@gmail.com wrote: I know i'm probably doing something REALLY stupid.but for some reason i can't get send/recv to work over ssh. I just built a new media server and Unless you need to have the send to be encrypted, ssh is going to slow you down a lot. I've used mbuffer when doing sends on the same network, it's worked well. pre-start an Mbuffer session on the receiving end somehow. SSH is always running on the receiving end, so no issues there. And you can always patch OpenSSH with HPN, thus enabling the NONE cipher, which disable encryption for the data transfer (authentication is always encrypted). And twiddle the internal buffers that OpenSSH uses to improve transfer rates, especially on 100 Mbps or faster links. -- Freddie Cash fjwc...@gmail.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] send/recv over ssh
Le 21 mai 10 à 02:44, Freddie Cash a écrit : On Thu, May 20, 2010 at 4:40 PM, Brent Jones br...@servuhome.net wrote: On Thu, May 20, 2010 at 3:42 PM, Brandon High bh...@freaks.com wrote: On Thu, May 20, 2010 at 1:23 PM, Thomas Burgess wonsl...@gmail.com wrote: I know i'm probably doing something REALLY stupid.but for some reason i can't get send/recv to work over ssh. I just built a new media server and Unless you need to have the send to be encrypted, ssh is going to slow you down a lot. I've used mbuffer when doing sends on the same network, it's worked well. pre-start an Mbuffer session on the receiving end somehow. SSH is always running on the receiving end, so no issues there. And you can always patch OpenSSH with HPN, thus enabling the NONE cipher, which disable encryption for the data transfer (authentication is always encrypted). And twiddle the internal buffers that OpenSSH uses to improve transfer rates, especially on 100 Mbps or faster links. Without patching anything, using arcfour instead of the default cipher increase the transfer rate dramatically. It is bounded by the Gb/s network here, not by ssh. Gaëtan -- Gaëtan Lehmann Biologie du Développement et de la Reproduction INRA de Jouy-en-Josas (France) tel: +33 1 34 65 29 66fax: 01 34 65 29 09 http://voxel.jouy.inra.fr http://www.itk.org http://www.mandriva.org http://www.bepo.fr ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
