SysadminNews

Btrfs fixup: dirty memory needs writeback preparation

On this page
  1. A merged correction, not just a pull request
  2. What the previous article overstated
  3. Why a clean scrub answers a different question

Btrfs restored a worker for dirty memory that bypassed the filesystem’s normal preparation. The fix protects future writeback; it does not reconstruct application data already lost.

Conceptual stored-data check: version A matches checksum A even if the application intended version B and B never reached storage. Scrub cannot infer the absent intended content.
Conceptual stored-data check: version A matches checksum A even if the application intended version B and B never reached storage. Scrub cannot infer the absent intended content. Chart : PeopleAreGeek. Data source.
View full-size image

A merged correction, not just a pull request

David Sterba’s August 6 request identifies silent data loss when dirty pages or folios lack the required COW fixup. Torvalds merged the restoration that day for the 7.2 release cycle. The change also flushes pending fixup work during unmount.

The code covers a concrete case: a direct-I/O read can dirty a shared file mapping without the ordinary delayed-allocation reservation. Writeback must arrange the missing preparation before submitting those blocks. Merely seeing a dirty flag does not establish that the filesystem has reserved the required space.

What the previous article overstated

The removal commit actually contains error messages and warning paths for unexpected dirty folios. Therefore “there is no log line” was an unjustified absolute. Equally, an absence of such a message does not prove that a particular system retained all intended data.

Assess a kernel by its patch history: did it include the removal, and did it receive the restoration? The upstream release-candidate window does not establish the contents of every downstream or custom build. The former blanket reassurance about all distribution kernels has been removed.

Why a clean scrub answers a different question

The official scrub documentation describes validation of stored data and metadata, including checksum and read errors. It does not compare files with what an application intended to write.

In our conceptual example, storage contains version A and a valid checksum for A. An application intended version B, but B never reached storage. Scrub may find A consistent with its checksum; it has no independent copy of B to use as the expected answer. This is an explanation of the boundary, not a reproduction of the kernel bug.

For a machine that ran an affected development build, preserving logs and identifying exact kernel revisions establishes exposure. Comparing important files with an independent known-good copy helps assess content. Installing the fix prevents the corrected failure path going forward; it cannot retroactively supply bytes that were never written.

September 8: verify the merged fix, remove absolute claims about absent diagnostics and all distribution kernels, and explain why scrub cannot validate application intent.