You don’t need tmux or screen for ZFS


Back in January I mentioned how to add redundancy to a ZFS pool by adding a mirrored drive. Someone with a private account on Twitter asked me why FreeBSD—and NetBSD!—doesn’t ship with a tmux or screen equivilent in base in order to daemonise the process and let them run in the background.

ZFS already does this for its internal commands. For example, I used zfs add to add a drive to fix a older RAIDZ2 pool, so I can just run:

# zpool status

Under status:

status: One or more devices is currently being resilvered.
The pool will continue to function, possibly in a degraded state.

The pool will also continue to be available, though potentially with reduced IO performance while it (re-)replicates.

The only time I use tmux is during a large ZFS send/receive operation between machines over SSH. At that stage we’ve introduced networks into the mix, which even the most robust, trustworthy storage system in the world can’t guarantee will stay up!

Author bio and support


Ruben Schade is a technical writer and infrastructure architect in Sydney, Australia who refers to himself in the third person. Hi!

The site is powered by Hugo, FreeBSD, and OpenZFS on OrionVM, everyone’s favourite bespoke cloud infrastructure provider.

If you found this post helpful or entertaining, you can shout me a coffee or send a comment. Thanks ☺️.