Btrfs removed its copy on write fixup worker during the Linux 7.2 merge window, on the reasoning that the kernel memory management layer had made the mechanism unnecessary. The reasoning was wrong, and the symptom was the worst kind there is: silent data loss, with no error returned and nothing useful in the logs. SUSE maintainer David Sterba sent a pull request on August 6, 2026 restoring more than 600 lines of that infrastructure, and Linus Torvalds took it for 7.2-rc7. If you have been running a 7.2 release candidate on btrfs, this is the item that matters this week. Stable 7.2 is expected later in August with the worker back in place.
The short answer
Btrfs dropped its copy on write fixup worker during the Linux 7.2 merge window, on the belief that the kernel memory management layer had eliminated the conditions it guarded against. It had not, and the result was silent data loss. SUSE maintainer David Sterba sent a pull request on August 6, 2026 restoring the infrastructure, and it is now in Linux Git for 7.2-rc7. Stable 7.2 is expected later this month. Only 7.2 release candidates were affected, so released and distribution kernels were never exposed.
There is a particular kind of bug report that makes filesystem developers go quiet, and it is not the one where the machine panics. A panic is loud, reproducible and dated. The bad one is the report where everything appeared to work and the data is not there.
That is what Btrfs found in the Linux 7.2 release candidates, and the correction landed this week. David Sterba of SUSE sent a pull request on August 6 restoring the copy on write fixup worker infrastructure that had been deleted a few weeks earlier. Linus Torvalds accepted it, and it is in Linux Git for 7.2-rc7.
What the worker was guarding
Btrfs never overwrites data in place. A change is written to a new location and the metadata is updated to point at it, which is what makes snapshots cheap and checksums meaningful.
That design has a requirement attached. Before a page can be written back, the filesystem needs to know it is coming, because it has to reserve space and create an ordered extent first. In the normal path this is fine, since the filesystem is the one marking the page dirty in the first place.
The fixup worker handles the abnormal path: a page that arrives already dirty, without btrfs having been told. Sterba described it as a mechanism to detect pages and folios that are marked dirty without filesystem knowledge and require copy on write fixup. Finding one, it performs the missing setup after the fact so the page can be written back properly.
The removal was reasonable, and wrong
During the 7.2 merge window the mechanism was dropped. The reasoning was that the memory management layer had changed enough that the conditions producing those unexpected dirty pages no longer occurred, which would make the fixup worker unreachable code.
Deleting genuinely dead code is good work, and 600 lines is worth deleting. The reasoning simply did not survive contact with running systems. The conditions still happen. With the net removed, the pull request states the consequence in five words: the consequence of not doing so is silent data loss.
Silent is the operative word
Most filesystem problems announce themselves. A write fails and returns an error. An I/O error reaches the application. Something appears in dmesg. A scrub reports a checksum mismatch and names the file.
None of that applies here. The data is not written, and the system carries on. A scrub afterwards does not help, because scrub compares stored data against stored checksums, and both describe what actually made it to disk. There is no record of what should have been there and was not.
This is why the change went in at rc7 despite its size. There is no log line an administrator can search for, no monitoring rule that catches it, and no way to audit a machine after the fact and be sure. The only reliable defence is a copy on a different filesystem.
Who was in the window
Only people running Linux 7.2 release candidates on btrfs, approximately rc1 through rc6. No released stable kernel shipped with the removal. If you run 7.1, a long term support kernel, or whatever your distribution ships, you were never exposed, and there is no action to take.
Landing more than 600 lines of feature code at rc7 is not how a release cycle is supposed to end. Sterba noted that roughly half of it is debugging and support machinery rather than core logic, which reduces the risk, and Torvalds took it regardless. The trade was a large late change against shipping a stable kernel that loses data quietly, and that is not a close call.
What we would take from this
The fix itself asks nothing of most readers. The habit it argues for is worth more.
Release candidates are for finding exactly this, and someone did, which is the process working. What the episode illustrates is why filesystem code is the wrong place to be early. Most pre-release breakage is loud, so the implicit bargain of running a release candidate is that you will notice a problem and roll back. Silent data loss removes that bargain. You do not notice, so you do not roll back, and the backup you did not verify is the only copy that still matters.
If you test kernels on real data, and there are good reasons to, keep the backup on a filesystem the kernel under test never mounted, and restore from it occasionally to check that it works. That advice is old and dull, and this is the failure mode it was written for.
Sources and further reading
- Linux 7.2-rc7 restoring Btrfs fixup worker infrastructure to address silent data loss, Phoronix, August 6, 2026
- Pull request restoring the fixup worker infrastructure, David Sterba, kernel mailing list
- Companion Btrfs fixes sent for the same release candidate
- Btrfs changes by kernel version, official documentation
Frequently asked questions
What does the fixup worker actually do?
It handles a case that should not happen but does. Btrfs is a copy on write filesystem, which means it does not overwrite data in place: it writes the new version elsewhere and then updates the metadata that points at it. For that to work, the filesystem has to know about every page that is going to be written back, because it needs to reserve space and set up an ordered extent before the writeback happens. The fixup worker exists for pages that get marked dirty without the filesystem being told. David Sterba described it as a mechanism to detect pages and folios that are marked dirty without filesystem knowledge and require copy on write fixup. When it finds one, it does the setup work after the fact so the page can be written back correctly instead of being dropped. It is a safety net for a path the filesystem does not control.
Why was it removed in the first place?
Because the conditions that create those unexpected dirty pages were believed to be gone. The memory management layer has changed a great deal over the years, and the reasoning during the 7.2 merge window was that it now prevented pages from reaching btrfs in that state, which would make the fixup worker dead weight. Removing code that is genuinely unreachable is good practice, and 600 lines of it is a real simplification. The problem was that the belief did not hold in practice. The conditions still occur, and with the safety net gone the pages had nowhere to go. This is a familiar shape in kernel work: a piece of defensive code outlives the explanation for why it was written, someone reasons that the cause is fixed, and the removal discovers that it was not.
Was I affected, and how would I know?
You were exposed only if you ran a Linux 7.2 release candidate, roughly rc1 through rc6, on a btrfs filesystem. No released stable kernel ever shipped without the fixup worker, so anyone on 7.1, on a long term support kernel, or on a distribution kernel was never in the window. The uncomfortable part is the second half of the question. Silent data loss means exactly that: no write error, no I/O error returned to the application, no message in dmesg, and a filesystem that continues to pass a scrub because the checksums match whatever was actually written. There is no log line to grep for after the fact. If you ran a 7.2 release candidate on data you care about, the honest answer is that you verify against a backup rather than against the filesystem itself.
Is it normal to restore 600 lines this late in a release cycle?
It is unusual, and that is the point worth reading. A release candidate cycle is supposed to narrow toward fixes that get smaller and safer as the final release approaches, and rc7 is the last stop before that. Landing more than 600 lines of feature code at that stage is the opposite of the normal trajectory, and Linus Torvalds took it anyway. Sterba noted that roughly half of the restored code is debugging and support machinery rather than the core path, which lowers the risk somewhat, but the size is still notable. The reason it went in is that the alternative was shipping a stable kernel that loses data without saying so. Between a large late change and a quiet correctness bug in a filesystem, the large late change is the safer of the two.
What should I do about my own kernel policy?
The specific fix needs nothing from you if you run released kernels: 7.2 will ship with the worker in place. The general lesson is the one worth keeping. Release candidates are for testing, and testing means hardware you can lose, not the filesystem holding data you cannot reproduce. Filesystem bugs are a particularly bad category for early adoption because they can be silent, which defeats the usual assumption that you will notice something going wrong and roll back. If you do run pre-release kernels on real data, and plenty of people have good reasons to, the practical protection is a backup on a separate filesystem that was never mounted by the kernel under test, plus the discipline to verify restores rather than assume them.