FreeBSD 13.0 Makes ZFS the Installer's Default Root Filesystem

The FreeBSD Release Engineering Team announced FreeBSD 13.0-RELEASE on April 13, 2021. The first release from stable/13 changed the default path through a new installation: on architectures with ZFS boot support, bsdinstall(8) presented Auto (ZFS) as the first partitioning method instead of Auto (UFS). It also replaced the legacy in-tree ZFS implementation with OpenZFS, making the installer choice and the storage implementation part of the same major-release transition.

What “ZFS became the default” actually means

The exact change is preserved in FreeBSD’s source history. Commit d512033e2a22, dated January 15, 2020, is titled “bsdinstall: Change default (first) Partitioning method to ZFS.” It reordered the interactive partitioning menu so pressing Enter on the first supported choice selected guided root-on-ZFS. UFS remained available, as did manual and shell-based partitioning.

This did not convert upgraded UFS installations to ZFS. A system moving from FreeBSD 12 to 13 kept its existing filesystem and partition layout. It also did not force ZFS onto architectures where the installer could not create a supported boot setup. The change affected the default choice during a fresh interactive installation on supported platforms.

That scope matters because “the default filesystem” can refer to several different things: which option is first in an installer, which implementation supplies the ZFS commands and kernel module, or which filesystem an existing machine uses. FreeBSD 13.0 changed the first two. It could not retroactively change the third.

OpenZFS replaced the legacy implementation

The 13.0 release notes state that FreeBSD’s ZFS implementation was now provided by OpenZFS. OpenZFS 2.0 unified development that had previously diverged between the illumos-derived FreeBSD code and ZFS on Linux. For FreeBSD, this meant moving to the shared upstream codebase while retaining operating-system-specific boot, GEOM, installer, jail, and administration integration.

OpenZFS brought features such as Zstandard compression and a common path for later improvements. Pool feature flags still required operational discipline. Enabling a new feature can prevent older rescue media or an older operating-system environment from importing the pool. An upgrade plan therefore needed compatible boot code and recovery media, not just a successful freebsd-update run.

The default installer layout created separate datasets, including a boot-environment root. That made bectl(8), added to the base system in FreeBSD 12.0, useful to far more fresh installations. Administrators could create a boot environment before a risky base-system update and select a preserved root if the new environment failed. Boot environments share one pool, however; they protect against some software changes, not pool loss, device failure beyond redundancy, or administrative destruction of the pool.

Snapshots likewise were not automatic backups. A new ZFS default made snapshot and replication tools available, but retention, off-host copies, monitoring, and restoration tests remained administrator responsibilities.

arm64 became Tier 1 and LLVM completed its takeover

FreeBSD 13 promoted 64-bit ARM, or AArch64/arm64, to Tier 1. Tier 1 status represented the Project’s highest support expectations for that architecture, including release engineering and build support. The announcement shipped arm64 images alongside amd64, i386, PowerPC variants, ARM, and RISC-V artifacts, with cloud images for both amd64 and arm64.

The base toolchain moved to LLVM 11.0.1. Obsolete binutils 2.17 and GCC 4.2.1 were removed from the source tree, and all supported architectures now used LLVM/Clang. BSD grep(1) became the default and the obsolete GNU grep previously in base was removed. These changes continued FreeBSD’s long effort to replace aging or restrictively licensed base components while keeping alternatives available through ports and packages where applications needed them.

Kernel TLS was another major addition. The kernel could frame and encrypt TLS records on TCP sockets, with support varying by TLS version, cipher, and transmit or receive direction. The base OpenSSL build did not enable KTLS by default; it required a KTLS-aware library and appropriate configuration. Calling it “automatic TLS acceleration for every application” would overstate what shipped.

Networking and filesystems gained protocol features

The NFS client and server added NFSv4.2 and extended-attribute support. NFS over TLS support also arrived, although the additional daemons were not built by default and the documented build needed KTLS-enabled OpenSSL. A new nfsv4_server_only setting let administrators avoid rpcbind(8) when serving only NFSv4.

FreeBSD 13.0 added a default kernel implementation for SEEK_DATA and SEEK_HOLE on filesystems without native sparse-file support and changed reads of directories to fail with EISDIR by default. These behavior changes could affect backup tools and scripts, which is why release notes and UPDATING are operational documents rather than marketing summaries.

Putting ZFS first lowered the knowledge barrier for boot environments, compression, checksums, snapshots, datasets, and send/receive replication. It also increased the number of users who needed to understand pool topology, scrub monitoring, snapshot space, and feature compatibility. Defaults make a path common; they do not make storage administration risk-free.

FreeBSD 13.0 is now historical and unsupported, so its original images and component versions are not appropriate for exposed production systems. Its lasting importance is the alignment of three transitions: OpenZFS became the in-tree implementation, guided ZFS became the first installer choice, and arm64 joined amd64 as a Tier-1 architecture while LLVM became universal across supported targets. Together, those changes defined much of the platform FreeBSD carried into later releases.

Related:

Sources: