Date: Thu, 08 Aug 2019 20:12:55 +0200 From: "Ronald Klop" <ronald-lists@klop.ws> To: freebsd-ports <freebsd-ports@freebsd.org>, "Freddie Cash" <fjwcash@gmail.com> Subject: Re: Any alternatives to NONE cipher ssh or bbcp for gigabit+ zfs send/recv? Message-ID: <op.z57t7t2bkndu52@sjakie> In-Reply-To: <CAOjFWZ6yummc09ypJbxvKQvzhk=vt2HzxBuhYW_qoNEgtPVS_Q@mail.gmail.com> References: <CAOjFWZ6yummc09ypJbxvKQvzhk=vt2HzxBuhYW_qoNEgtPVS_Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 08 Aug 2019 19:13:24 +0200, Freddie Cash <fjwcash@gmail.com> wrote: > We have gigabit fibre between our main data centre and our off-site data > centre across town. We do zfs send/recv of our backups between the sites > over a dedicated gigabit fibre link. Our ZFS storage servers are running > older AMD Opteron (pre-bulldozer) CPUs, so there's very little in the way > of encryption extension support. > > Running zfs send/recv over regular SSH gives horrible throughput (100-250 > Mbps max). > > In the past, we compiled the openssh-portable port with the HPN patches > and > NONE cipher. That allowed us to saturate the gigabit link for zfs > send/recv and rsync transfers. Then those were removed from the port and > base OpenSSH. (There were patches floating around for awhile, but we try > not to build from source anymore.) > > Then we found bbcp, which works great for the zfs send/recv process, > saturating the gigabit link. Doesn't work for rsync, but that's okay (we > only use rsync for our regular backup process, and that's limited by the > remote school's Internet link). > > An update [1] to the bbcp port broke some things, but we found the > magical > combination of command-line options to make it work reliably in our > environment. And a project was underway to update bbcp [2] to a newer > version and make it work better on FreeBSD, but it fizzled out. And now > the bbcp port has been removed. > > We have an archived copy of the bbcp package that works for us on FreeBSD > 12 (amd64). We'll continue to use that as long as it works (probably > until > FBSD 12 is EoL). > > Are there any alternatives to HPN/NONE cipher / bbcp to allow an older > Opteron system to saturate a gigabit link with zfs send/recv or rsync? > This is strictly over a private network, so encryption is only needed for > the authentication bit, not for the actual data transfer. Preferably > something that's available in the ports tree as a binary package. :) > > Suggestions? > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197035 > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229115 > > (Thanks to all who attempted to keep bbcp working on FreeBSD. Sounds > like > it wasn't much fun, but we really appreciate the effort.) > Does mbuffer do the job for you? https://www.freshports.org/misc/mbuffer It has minimal support for limiting which host can connect: -I <h>:<p> : use network port <port> as input, allow only host <h> to connect https://www.freebsd.org/cgi/man.cgi?query=mbuffer&sektion=1&apropos=0&manpath=FreeBSD+9.0-RELEASE+and+Ports Something like this might work: Server: mbuffer -I client-ip:8000 | zfs recv Client: zfs send | mbuffer -O server-ip:8000 You might setup the server process using ssh to keep it flexible. Client: ssh -F server-ip 'mbuffer -I client-ip:8000 | zfs recv' Client: zfs zend | mbuber -O server-ip:8000 Regards, Ronald,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.z57t7t2bkndu52>