Analyses / Filesystem recovery

F2FS: when a successful fsync is not a recovery promise

Published 15 October 2026 / Linux source audit and research review

In the audited Linux v6.12 and v6.16 regular-file path, F2FS can return success from fsync with checkpointing disabled, before writing the recovery metadata handled later in that function. A zero return must be interpreted alongside the filesystem configuration, not used as a configuration-independent recovery promise.

Two ways to make a recoverable state

F2FS is a Linux filesystem designed for flash-backed block devices. Lee and colleagues' FAST 2015 paper distinguishes a consistent checkpoint from later file updates recovered through a separate mechanism. Its design alternates checkpoint packs, retaining a stable recovery point while constructing another. [1, section 2.7]

Making every small synchronized write checkpoint unrelated metadata would be expensive. Roll-forward recovery instead uses specially marked node blocks to reconstruct selected post-checkpoint updates. This is recovery work, not a rule that every byte written after a checkpoint must survive. [1, section 2.7.2]

The implementation still has a full-checkpoint fallback: the v6.12 source checks conditions including hard links, compressed files and insufficient roll-forward space. "fsync always checkpoints" and "fsync never checkpoints" are both too broad. [3, need_do_checkpoint]

The configuration trap: checkpoint=disable

The Linux 6.12 manual documents that, while checkpointing remains disabled, unmounting or unexpected shutdown exposes the state from when this mode was entered. It also warns of temporarily unusable capacity. This changes the recovery contract; it is not simply a longer checkpoint interval. [2]

Our source inspection follows the regular-file path through f2fs_do_sync_file: it calls file_write_and_wait_range, then returns that status when SBI_CP_DISABLED is set. Successful data writeback therefore permits zero here without the later recovery-node and flush handling. Calling this an unconditional no-op would also be wrong: the writeback step precedes the return. [4]

Scope matters: directories branch to a different label before this sequence. The finding is not a claim about every directory sync, ioctl or vendor kernel. It describes the reviewed regular-file branch, not a newly discovered default-mode filesystem defect. [3]

Generated source observations, not power-loss measurements.
Upstream tag	Data writeback first	Disabled-checkpoint return	Directory path
v6.12	Yes	Returns writeback status	Separate branch
v6.16	Yes	Returns writeback status	Separate branch

The mount code supplies the other half of the explanation: a checkpoint carrying CP_DISABLED_FLAG skips the normal fsync-data recovery path. Physical data writes and reconstructing the newer filesystem view are different events. [5]

Three switches, three different questions

Configuration boundaries; these are not tuning recommendations.
Policy	Boundary it changes	Do not infer
`checkpoint=disable`	Advancement of the filesystem recovery point.	That successful regular-file fsync preserves the newer view. [4]
`norecovery`	Roll-forward recovery on mounting; the documented option requires read-only use.	That missing post-checkpoint updates were never written. [2]
`fsync_mode=nobarrier`	The documented policy omits flush commands for non-atomic files.	That write completion proves volatile device caches are persistent. [2]

There is another subtle limit: disabling roll-forward does not mean skipping every mount-time action. In v6.16, orphan-inode recovery occurs before the branch that selects fsync-data recovery. A replay option alone is not a forensic write-blocking guarantee. [5] Compare the separate Btrfs read-only and replay boundaries.

What the newer paper does, and does not, establish

Cui and colleagues' OSDI 2025 F2FSJ work replaces coarse checkpoint work with decentralized, epoch-based metadata-change journaling. Section 5 evaluates a prototype on Linux 5.15.39; the end-to-end comparison uses F2FS POSIX mode. Reported measurements average at least ten runs. [6, sections 5.1-5.3]

For four Filebench metadata workloads, section 5.2 compares F2FS checkpoint time with F2FSJ journal time, reporting ratios up to 4.9. That is a component-time comparison, not a universal 4.9-fold application speedup. The authors also discuss recovery ordering in section 2.3. These findings motivate testing a concrete configuration; they do not establish identical behavior on every later kernel. [6]

We did not reproduce F2FSJ or measure storage performance. The older FAST paper explains the architecture; the newer paper evaluates an alternative; our pinned code audit establishes a narrower implementation fact. Those evidence types should remain separate.

Reproduce the source check

Run node audit-f2fs-sync.mjs using the audit script. It downloads two pinned source files, records their SHA-256 hashes and checks ordered landmarks within the named function. The generated JSON records the actual generation time and scope.

The checker fails when the expected branch structure changes. It is a bounded lexical audit, not a C parser or proof that all runtime paths are correct. Distribution backports require their own inspection. No filesystem was formatted, mounted, repaired or power-cut for this publication.

An evidence checklist before a benchmark

Hesela's engineering conclusion is to define the recovery promise before comparing latency. Record the kernel build, effective mount options, exact operation and return value, device-cache assumptions, and whether recovery was deliberately skipped. A faster result under a weaker promise is not an equivalent performance result.

For future disposable crash tests, distinguish acknowledged file updates, durable directory entries, checkpoint-only views and normally recovered views. State the expected outcome before injecting faults. That is a proposed validation protocol, not an experiment completed here.

Primary sources

Reviewed 15 October 2026. Upstream tags are pinned, not claims about the newest release. No DOI is asserted where none was verified in the publisher record.