I then started atop to observe how the transfer proceeded. I wanted to make sure that that connection was used for the transfer.
The reason for explicitly specifying the ip address and not the host name of the receiving server is because, in addition to normal gigabit network connections via a switch, both servers also have a direct 10Gb/s link (two Mellanox ConnectX EN PCIe 2.0 cards).
#OPENZFS LINUX MEMORY REQUIREMENTS SERIES#
On the sending side, I started the following to send an incremental series of snapshots: sudo zfs send -I | \ The -r option shows the rate of data transfer, the -t option shows the transfer time, the -a option shows the average transfer rate, and the -b option shows the total bytes sent. The pv tool displays the progress of data transfer. The 1 GB I specified is probably a bit big, but since both machines had ample RAM, this was of no concern. The -s option sets the block size of the buffer, given that ZFS’ default block size is 128 kB, I chose the same size. In addition to nc I also added mbuffer 1 to act as a buffering layer. Here the -l option to nc tells it to listen on port 8000. On the receiving end (the backup machine), I ran nc -l 8000 | \ Since nc doesn’t encrypt anything (like SSH would) and only acts as a simple pass-through this should indeed give best performance. As various other websites will tell you, the fastest way to transfer data over a local network is with the netcat ( nc) utility.
Since both servers were in the same trusted local network, there was no need for encryption. I recently had to send a couple of ZFS file systems from one server to another, both running Ubuntu Linux 16.04. Improving transfer speeds for ZFS send/receive in a local network Computing, Hardware, Linux, networking, Server, software, ZFS Posted on 14 November 2016 by Lennart Karssen
0 kommentar(er)
