Research notes / Filesystem logging

XFS delayed logging: which commit is durable?

Published 2026-10-15 / Source review, not a benchmark

An XFS transaction can finish in memory before its recovery record is durable. A fast metadata operation is not automatically a fast durable operation.

Three boundaries, not one

Delayed logging coalesces repeated metadata changes before journal writes. The design distinguishes these stages. [1]

Conceptual stages; relogging can overlap them. Not a trace from a running filesystem.
Stage	Evidence	Still not established
In-memory commit	CIL holds formatted changes.	Journal persistence.
Checkpoint completion	Recovery information reaches the journal; items enter the AIL.	Home-location writeback.
Home writeback	Items leave the AIL, permitting log-tail progress.	Application-level multi-file atomicity.

Definitions: delayed logging, Committed Item List and Active Item List.

A checkpoint means different work

JBD2 checkpointing writes already-committed buffers to their home locations and supports journal-space reclamation. [4] XFS calls its batched journal transaction a checkpoint. [1] Translating either word without naming the subsystem reverses the apparent direction of the write.

The journal-checkpoint glossary entry uses the JBD2 meaning. Compare ext4 commit and checkpoint.

What ScaleXFS tested

Kim and colleagues' FAST 2022 study used Linux 5.8.5; its evaluation used a four-socket, 112-core server, 512 GB DRAM and an Intel Optane 905p. It addressed logging contention with double CILs, per-core lists and strided accounting. This is a historical experimental configuration. [3, sections 4-5]

The workload details are decisive: modified varmail gave each thread its own directory; Exim disabled per-message fsync(). In FxMark's shared-directory case, the full design did not improve performance over XFS because shared-metadata contention remained. The private-directory gain was not universal. [3, sections 3.1 and 5.3, Figure 21]

Hesela's inference: compare concurrency and persistence requirements before comparing throughput. Disabling synchronization changes the question. These results do not establish a speedup on a current distribution, and we did not reproduce the experiments.

The newer source is not the paper's baseline

Our Linux v6.16 source check finds per-CPU item insertion in xlog_cil_insert_items and aggregation in xlog_cil_push_pcp_aggregate. It also checks that xlog_cil_flush initiates work without waiting for completion. A function named flush is not sufficient evidence of a synchronous durability barrier. [2]

This establishes selected source features, not that ScaleXFS was merged, that the implementations are equivalent, or that a bottleneck disappeared. Distribution backports also require separate inspection.

Download the source checker and generated receipt. Run node audit.mjs with Node 22 or later; it fetches the pinned source, reports SHA-256 and line locations, and fails if a checked feature is absent. It does not execute kernel code. To inspect a cached copy, pass its path as the first argument and compare its hash with the receipt.

Keep the application contract explicit

On Linux, successful fsync() covers file data and associated metadata; persisting the containing directory entry requires a separate directory synchronization. Errors must be checked. [5] Neither a benchmark's operation count nor an internal function return substitutes for that contract.

For an engineering comparison, record kernel and filesystem options, directory sharing, operation mix, synchronization frequency and latency distribution. Keep those inputs fixed while investigating the bottleneck. This is an editorial measurement checklist, not a tested tuning prescription.

Primary sources

Reviewed 2026-10-15. No third-party figures reproduced.