Synopsis #
ZFS and UFS are both first-class FreeBSD filesystems, but they solve different operational problems. ZFS integrates checksums, datasets, snapshots, replication, compression, and pool management. UFS provides a smaller traditional filesystem boundary with mature repair and dump/restore tools.
The useful choice is not which filesystem is universally better. It is which failure modes, recovery procedures, and administrative costs fit the host.
Choose from operational requirements #
| Requirement | Likely fit | Qualification |
|---|---|---|
| Checksummed data and metadata | ZFS | Redundancy is still needed to repair detected damage automatically. |
| Frequent snapshots and replication | ZFS | Snapshots on the same pool are not independent backups. |
| Separate properties or quotas for many workloads | ZFS datasets | Dataset boundaries should follow backup and delegation boundaries. |
| Small, simple, or memory-constrained installation | UFS may fit | Measure the actual platform and workload rather than using a universal memory rule. |
| Traditional full-filesystem dump and restore | UFS | dump operates on a filesystem, not an arbitrary directory tree. |
| Boot environments | ZFS | Confirm the installed boot-environment tooling and preserve pool compatibility. |
Neither choice removes the need for backups, monitoring, capacity planning, and recovery practice.
Make datasets follow policy #
On ZFS, a dataset deserves to exist when it needs a distinct property or lifecycle, such as:
- a separate snapshot or retention schedule;
- a different mount point, quota, compression setting, or delegation boundary;
- independent replication or restoration;
- a jail, virtual machine, database, or user-data boundary.
Avoid creating datasets merely to reproduce every directory. Excess boundaries increase snapshot, mount, and replication complexity without adding policy.
Inspect the installed layout before adding one:
$ zpool status
$ zfs list -o name,mountpoint,used,available,compression
Make UFS filesystems follow recovery boundaries #
Separate UFS filesystems can limit space exhaustion and allow independent fsck, dump, and restore operations. They also create fixed allocation boundaries that are harder to change than a ZFS dataset quota.
Inspect devices, partitions, and mounted filesystems before planning a change:
$ gpart show
$ mount
$ df -h
Do not infer an unmounted partition’s purpose from its device name. Record labels, partition types, /etc/fstab, and backups before formatting or resizing it.
Design redundancy and backup separately #
A ZFS mirror or RAIDZ vdev can keep a pool available after certain device failures. It does not protect against deletion, destructive administration, compromised credentials, fire, or loss of the entire host. A UFS filesystem on a hardware mirror has the same distinction.
Define three separate controls:
- Availability: which device failures the local layout must survive.
- Recovery point: how far data may roll back after loss or corruption.
- Recovery location: which independent system or medium retains the copy.
The ZFS operations hub separates snapshots, selected-file restoration, local and remote replication, integrity checks, and device replacement. Begin with snapshot and replication , then document selected-file restoration and an independent remote replication path .
Plan replacement before buying capacity #
Record device models, sizes, sector characteristics, controller paths, and the physical slot corresponding to each provider. Replacement is safer when the failed device can be identified without guessing from ada0 or da1 alone.
For ZFS, inspect the topology rather than treating pool size as redundancy:
$ zpool status -P
$ zpool list
Adding a second single-disk top-level vdev expands a striped pool; it does not turn the first disk into a mirror. Pool topology changes deserve their own reviewed procedure.
Schedule pool-health and scrub review before a failure. The failed mirror-device procedure is intentionally limited to a simple topology; it is not a generic replacement recipe for RAIDZ, dRAID, special, or deduplication vdevs.