UFS Soft Updates and Journaling on FreeBSD: What Each Mechanism Protects
How UFS Soft Updates, SU+J, fsck, and GEOM journaling differ, including crash guarantees, stable-write semantics, inspection, and safe changes.
FreeBSD’s UFS reliability options are often collapsed into one word—“journaling”—even though Soft Updates, Soft Updates with journaling (SU+J), and GEOM gjournal operate differently. Choosing or repairing them requires knowing which layer orders metadata, which layer records recovery information, and what an application can infer after fsync().
Soft Updates orders metadata dependencies
Traditional synchronous metadata writes preserve consistency but can be expensive. Soft Updates tracks dependencies between metadata changes and allows writes to be delayed or reordered while preventing unsafe on-disk relationships—for example, a directory entry pointing to an inode that has not been initialized.
After a crash, the filesystem should remain structurally safe, but unreachable allocations and other deferred cleanup can remain. Background or foreground fsck_ffs reconciles that state. Soft Updates is not a journal of user data and does not guarantee that unsaved application content survives power loss.
Inspect a mounted UFS filesystem and its superblock state rather than assuming installer defaults:
mount -p
dumpfs -m /dev/ada0p2dumpfs -m prints a newfs-style reconstruction, including relevant flags. Use the actual provider for the filesystem and preserve the output before changing anything.
SU+J adds a small metadata journal
Soft Updates journaling records information needed to accelerate recovery of the allocation state managed by Soft Updates. On restart, fsck_ffs can replay the journal in seconds in ordinary cases instead of scanning an entire large filesystem.
SU+J does not turn UFS into a data-journaling filesystem. Application data that was never durably written may still be lost, and storage that lies about cache flushes can defeat higher-level guarantees. Hardware error, journal corruption, or severe inconsistency can still require a full check.
newfs and tunefs expose the relevant creation and modification flags. Never toggle them on a mounted read-write filesystem merely because a blog shows a command. Back up the data, boot into a maintenance environment when required, unmount the filesystem, verify the provider, and follow the installed release’s tunefs(8) restrictions.
GEOM journaling is a different layer
gjournal creates a GEOM provider below the filesystem and journals block writes. UFS must be created/configured to cooperate with that provider. Current FreeBSD documentation treats SU+J as the normal choice and GEOM journaling as specialized or legacy because it adds another storage layer and changes operational semantics.
The FreeBSD journaling article specifically warns that sync(2) and fsync(2) on a GEOM-journaled setup do not carry the ordinary guarantee that data is committed to stable storage; gjournal sync is the relevant operation. That difference is critical for databases and other applications whose durability model assumes standard fsync behavior.
Do not stack recipes indiscriminately. A gjournal setup historically disables Soft Updates and uses the UFS -J cooperation flag, while SU+J uses filesystem-integrated soft-update journaling. The letters in command options are easy to confuse; the resulting semantics are not interchangeable.
Recovery protects consistency, not every byte
All three designs address filesystem consistency after interruption. None substitutes for a backup, validates silent media corruption end to end, or preserves an application transaction that never reached its durability boundary. A power-loss test must include the storage controller and actual flush behavior, not only a virtual machine reset.
On restart, capture console messages and fsck_ffs output. If journal replay fails, stop repeated write attempts, preserve an image when data matters, and diagnose underlying I/O errors before forcing repairs. A journal cannot repair unreadable sectors or RAM corruption.
Make changes with a rollback path
Before enabling or disabling an option, record FreeBSD version, UFS version, provider topology (geom disk list, gpart show), mount options, dumpfs -m, SMART/controller health, and a verified backup. Test the exact change on equivalent disposable media.
Afterward, confirm mount output, superblock flags, clean unmount/remount, a controlled crash-recovery exercise on noncritical data, and application durability tests. The right configuration is the simplest supported mechanism whose guarantees match the workload—not whichever command includes the word “journal.”
Related:
- kqueue and kevent: FreeBSD’s Native Scalable Event Notification Interface
- How to Automate FreeBSD Device Events Safely with devd Rules
Sources: