Any alternatives to NONE cipher ssh or bbcp for gigabit+ zfs send/recv?

Ronald Klop ronald-lists at klop.ws
Thu Aug 8 18:13:05 UTC 2019


On Thu, 08 Aug 2019 19:13:24 +0200, Freddie Cash <fjwcash at 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,


More information about the freebsd-ports mailing list