ZFS send/receive accross different transport mechanisms

Sending ZFS snapshots across the wires can be done via multiple mechanisms. Here are examples of how you can go about it and what the strengths and weaknesses are for each approach.

SSH

strengths: encryption / 1 command on the sender

weaknesses: slowest

command:

zfs send tank/volume@snapshot | ssh user@receiver.domain.com zfs receive tank/new_volume

NetCat

strengths: pretty fast

weaknesses: no encryption / 2 commands on each side that need to happen in sync

command:

on the receiver

netcat -w 30 -l -p 1337 | zfs receive tank/new_volume

on the sender

zfs send tank/volume@snapshot | nc receiver.domain.com 1337

(make sure that port 1337 is open)

MBuffer

strengths: fastest

weaknesses: no encryption / 2 commands on each side that need to happen in sync

command:

on the receiver

mbuffer -s 128k -m 1G-I 1337 | zfs receive tank/new_volume

on the sender

zfs send tank/volume@snapshot | mbuffer -s 128k -m 1G -O receiver.domain.com:1337

(make sure that port 1337 is open)

SSH + Mbuffer

strengths: 1 command / encryption

weaknesses: seems CPU bound by SSH encryption, may be a viable option in the future?

command:

zfs send tank/volume@snapshot | mbuffer -q -v 0 -s 128k -m 1G | ssh root@receiver.domain.com 'mbuffer -s 128k -m 1G | zfs receive tank/new_volume'

Finally, here is a pretty graph of the relative time each approach takes:

SSH + MBuffer would seem like the best of both worlds (speed & encryption), unfortunately it seems as though CPU becomes a bottleneck when doing SSH encryption.

MDNS/Bonjour printer discovery script

Here’s a script I wrote whose purpose is to discover the printers that are currently being advertised by Bonjour on the network. The reason I wrote it was for a Nagios check that would in term verify that our printers were present. Writing it took me through the meanders of MDNS in Python & on Linux with multiple vlans. Let’s just say non-trivial.

Download

find_mdns_printers_1.0.tar.gz

Sample output

FreeBSD 9.0: higher MTU & NIC bonding

Here’s is some information that took me a good while to gather.

With the igb driver in FreeBSD, the mbuf cluster size needed is a mathematical formula involving the number of CPUs & the desired MTU. Unfortunately, it is currently hard set. On enterprise machines with many cores and higher MTUs, it is quite easy to reach this set limit. It will express itself with the following error message after an ifconfig:

igb0: Could not setup receive structures

This limit can be overridden with the following in /etc/sysctl.conf

kern.ipc.nmbclusters=131072
kern.ipc.nmbjumbo9=38400

These are the value that worked for 16 cores & an MTU of 9000.

While we’re at it, it took me a while to nail the exact syntax require for NIC bonding so here it is:

/etc/rc.conf

if_lagg_load="YES"
ifconfig_igb0="mtu 9000 UP"
ifconfig_igb1="mtu 9000 UP"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport igb0 laggport igb1 192.168.0.123 netmask 255.255.255.0"

As far as I can tell, capitalization matters…