Analyses / Filesystem recovery

Soft updates: consistent metadata without a full journal

Published 15 October 2026 / Historical papers and a constructed model

A filesystem can preserve safe metadata relationships without logging every metadata change. That does not promise that every recent application update survives, or that every byte of free space is immediately reclaimable.

Order the dependency, not every system call

Soft updates tracks individual metadata dependencies and enforces them during writeback. A new pointer must not expose an uninitialized object; a resource must not be reused while old references remain. [1]

Whole-block dependencies can form cycles because one block contains many independent changes. The 1999 BSD implementation temporarily rolls back unsafe changes in a buffer, writes a safe image, then restores the newer in-memory values. This is selective writeback, not an application-visible transaction rollback. [1]

The trade-off includes dependency tracking and deferred reclamation. Journal replay instead uses persisted recovery information. These are different mechanisms for controlling intermediate persistent states, not synonyms for data durability.

This article describes the classical mechanism. FreeBSD 14.3 separately exposes soft updates and soft updates journaling settings; an actual UFS installation can use both. The latter adds log writes to shorten cleanup, but its journal cannot repair errors it never recorded. [5]

A pointer can be too early in two different ways

Consider one initially free, uninitialized and unreferenced block. In our deliberately simplified model, A marks it allocated, D initializes its contents and P publishes a pointer. Each action is an atomic persistent change. The invariant is: whenever P is present, both A and D must be present.

This model enumerates all six permutations and four interruption boundaries per permutation, including before the first write. A and D may occur in either order; P needs both. The model abstracts the allocation dependencies discussed in section 2 of the 1999 paper; it does not implement its buffer rollback machinery.

Constructed results, not measured failures. Prefix numbers count completed persistent actions. Repeated states occur in different traces.

Persistent order	Unsafe prefixes	Safe at every boundary?
`A / D / P`	None	Yes
`A / P / D`	2	No
`D / A / P`	None	Yes
`D / P / A`	2	No
`P / A / D`	1, 2	No
`P / D / A`	1, 2	No

All six final states satisfy the invariant. A test that checks only after everything finishes would miss all the bad intermediate states. Conversely, the A/D prefix is safe but has allocated space without a persistent pointer. Safety is not the same as reclamation, nor proof that a new file is durably reachable.

There are 24 order-prefix pairs, six unsafe pairs and two orders safe throughout. These are exhaustive counts in this state space, not crash probabilities. No distribution over real write scheduling or interruption time was measured.

Download the results with assumptions and code hash, model and tests. With the two code files together, run node --test soft-updates-ordering.test.mjs. No packages or storage devices are needed. Torn writes, volatile caches, concurrency, errors and recovery are outside the model.

Why the benchmark contract matters

Seltzer and colleagues compared soft updates with several journaling configurations in a common FFS setting. Their 2000 study separates synchronous from asynchronous logging and same-disk from separate-log-disk arrangements. Workloads included microbenchmarks, Netnews, SDET and PostMark. [2]

Results changed with workload and write policy: deferred deletion helped some runs, while short buffer residence reduced aggregation. The useful lesson is to compare persistence promises and workload behavior before comparing elapsed times. This is historical implementation evidence, not a ranking of present-day UFS, ext4, ZFS or NVMe devices. We have not reproduced these benchmarks.

Background checking needs a restricted repair problem

McKusick's 2002 design runs checking against a snapshot, then reclaims lost resources through kernel interfaces while the live filesystem continues. The snapshot supplies a stable view; it is not an ordinary scan racing arbitrary filesystem changes. [3]

Reported idle-filesystem snapshot timings, not fsck completion times. Source: 2002 paper, table 1. Test system: FreeBSD 5.0-current dated 30 December 2001, dual Celeron 350 MHz, SCSI storage; filesystems were 90% full.

Reported size	Total elapsed time	Filesystem suspension
0.5 GB	0.7 s	0.025 s
7.7 GB	3.5 s	0.034 s

The short suspension is only one interval inside the operation. It is not evidence of zero overhead or a modern latency guarantee.

The version-pinned FreeBSD 14.3 manual limits background checking to eligible filesystems. Unexpected errors cause it to request foreground checking and stop further cleaning. Soft updates must be enabled, the filesystem must be writable and mounted, and it must not already require a foreground check. [4] These conditions are part of the contract.

Three questions to keep separate

For an engineering review, ask whether persistent references are safe, whether unused allocations have been reclaimed, and whether the application's required update survived. Our model answers only the first question for its tiny state space. Successful mounting or checking cannot substitute for an application-specific recovery oracle.

Related reading: crash-test oracles, durable rename and scrubbing boundaries. Corpus: metadata update dependency and background fsck.

Primary sources

Source review: 15 October 2026. Historical claims retain their original scope. No unverified DOI, modern benchmark or physical crash test is claimed.