FreeBSD Features

ZFS offers many feature you’d expect from a file system like the ability to format a storage device as ZFS and see how much storage space you have available. But where most file systems expect a single device, ZFS can handle the task of making several devices work together as a "storage pool."

In the example depicted you can see a 32.7 TB zpool called "zstore". The zpool-status(8) output tells us that zstore is made of up four ada(4) devices, that are configured as two striped mirrors. In this configuration, any disk could fail and zfs would alert you and allow you to replace it, and all without powering down. In addtion, features like zpool-scrub(8) allow you to proactively check your devices for inconsistencies and correct them when found.

With an available storage pool, you can start creating data sets. You simply zfs-create(8) them and you immediately have an accessible directory with its own independent set of attributes. It replaces the need to manage attributes and mount points in fstab(5). Moreover, it opens many new possibilities, like the ability to snapshot data (and revert to a snapshot if needed).

In the example shown, we see a new data set called stuff on the ZFS storage pool zroot is created and mounted at /usr/local/stuff. After creation, an imporant document important_doc.txt is added. Because it’s so important a snapshot of the data set is created called justincase. Sometime later, all files in /usr/local/stuff are accidentally deleted. With zfs-rollback(8) this mishap is easy to resolve. Setup your own snapshot solution, or use ports like sanoid and zrepl to manage it for you.

A ZFS boot environment is a bootable snapshot of preselected parts of a system. They are designed to allow you to boot to known good states. When performed before any substantial change, they reduce the risk tp effectively nothing. For example, if you had a power failure during a system upgrade that resulted ina corrupt system, you could simply restart the system and it would default to the snapshot automatically created before your upgrade. The result is tour system will start in exact the state it was in prior to the start of the upgrade.

The primary interface to manage boot environments is bectl(8). In the example, the user wanted to try out the BETA pre-releases for 14.3. Any pre-release software can be risky, but with boot environments should that BETA turn out to do something destructive the user could simply revert back to a previous state. Moreover, you can create your own boot enviroments at any time. In the latter portion of the example it seems the user is about to attempt installing the CURRENT branch of FreeBSD. With boot environments this can be attempted stress free.

Getting started with virtualization can be daunting as there are so many things to consider. Luckily, a port called vm-bhyve will get you going quickly. Morevover, it keeps an exact log of the bhhyve commands it constructs for you, so when you feel bold enough to fine-tune your virtual machine, you’ll have an excellent starting point.

In the example, we see that in just four commands the user is able to get a new VM up and running. (As side note, there are a few setup steps the first time you use vm-bhyve, but they’re quite simple too and well documented in the manual.) More importantly, vm-bhyve keeps logs with exact details about how our VM was started. This provides an excellent primer for when the user wants to try more nuanced setups.

Jails can be directly managed, but ports like Bastille wrap the jail command in thoughtful logic to make most jail setups very simple to accomplish.

The Bastille site has a nice getting started with Bastille document. The example here gives a brief feel for how simple managing jails can be. It appears the user wants a jailed web server. In one command they name and create a jail called "webserver" with a specific release of FreeBSD and its own IP address. And with that command, it’s ready to go! From here the user can issue commands from the host, or connect to the guest’s console and manage it just like any other FreeBSD instance. And since it has it’s own IP, an ssh service can be started and allow this user to remotely manage the web server without ever touching the host environment.

The FreeBSD Handbook is one of the hallmarks of FreeBSD documentation. If you were taking a college course on FreeBSD, this would be the course text book. It starts with concepts, walks you though the steps to get up and running, and then steps through every core feature of the OS.

Like all FreeBSD documentation, not only is the FreeBSD Handbook informative, it is also very accessible. As the screen shot shows, you can view the handbook in a graphical browser, in a text based browser, or in a printable PDF format. Regardless of whether you’re a casual user or a kernel developer, FreeBSD’s documentation has something for you and in a format that meets your needs.

The FreeBSD Foundation publishes regular updates on a variety of topics, but one well-curated means of communication is the FreeBSD Journal. Published every other month, the Journal spotlights original content from throughout the FreeBSD community.

In the Journal you’ll from articles from people in leadership positions within the project, such as the head of the Release Engineering Team. You’ll find colorful interactions from community icons and prolific authors. You’ll hear perspectives from people who attented conferences and summits. And you’ll get great in-depth articles from people who are passionate about problems they’ve solved and eager to share. It’s just a small piece of what makes the FreeBSD community so great.