WinBtrfs, the open source Btrfs driver that lets Windows read and write Linux formatted volumes, shipped version 1.10 on September 1, 2026. It is the first release since March 2024, and the changelog is short enough to read in a minute but contains one entry that matters more than the rest: an extent tree corruption bug when writing to snapshots is now fixed. Around it sit two new write paths, a crash that Steam reliably triggered, a preallocation fix that unbreaks rclone, and one quiet regression on removable devices. We went through what changed and who should upgrade first.
The short answer
WinBtrfs 1.10 shipped on September 1, 2026, the first release of the Windows Btrfs driver since March 2024. It adds write support for free space bitmaps and compressed inline files, both of which could already be read, improves handling of removable devices and tightens error recovery under out of memory and out of disk conditions. The fix list includes extent tree corruption when writing to snapshots, a crash when moving files across subvolumes, a crash when many files are created at once as the Steam client does, a preallocation bug that broke rclone, a deadlock on hard link queries and memory corruption related to watching the Registry. RAID on removable devices is no longer supported.
There is a specific kind of tool that only matters twice a year and matters enormously on those two days. WinBtrfs is one of them. It is a Windows kernel driver that mounts Btrfs volumes read and write, it works back to Windows XP, and it is usually the answer when a dual boot machine needs to reach the Linux side from Windows, or when a Linux box will not come up and the only working machine nearby runs something else.
Version 1.9 came out in March 2024. Version 1.10 came out on September 1, 2026. In a project like this one, a two and a half year gap is not abandonment, it is a single maintainer working against a filesystem that keeps evolving on the other operating system.
Read the corruption fix first, then the feature list
The changelog opens with features, which is conventional, but the entry to act on sits in the middle of the fixes: extent tree corruption when writing to snapshots.
The extent tree is the structure that records which physical extents exist and who references them. Corrupting it is not the kind of failure that announces itself with a blue screen. It is the kind that surfaces weeks later, when a scrub reports errors or a file you have not touched since spring reads back wrong. If you have been writing to Btrfs snapshots from a Windows machine on 1.9, the correct order of operations is upgrade the driver, then boot Linux and run a scrub across the volume, then decide whether you trust it. Do not do it the other way round.
The rest of the fix list is more ordinary and more visible. A crash when moving files across subvolumes, which includes sending a file to the Recycle Bin if your recycle bin lives on a different subvolume. A crash when a large number of files are created simultaneously, observed with the Steam client, which is exactly the workload a game install produces. A deadlock when querying hard links. Memory corruption related to watching the Registry. Preallocation issues that broke rclone, which matters to anyone syncing a cloud remote onto a Btrfs volume from Windows. Disk usage statistics for multi device volumes now report correctly, and FSCTL_DUPLICATE_EXTENTS_TO_FILE works when sent from 32 bit userspace.
Two write paths that stop Windows writing a second class layout
The two new features are both cases where the driver could read a structure but not produce one.
Free space bitmaps are the compact form the free space tree uses when a block group is fragmented enough that listing individual free extents costs more than a bitmap would. WinBtrfs could read them already. Now it can write them, which means a volume that Windows has been writing to no longer drifts toward a less efficient free space representation than the same volume would have under Linux.
Compressed inline files are small files stored directly inside their metadata item rather than in a separate data extent, compressed in place. Again, reading worked; writing did not. The practical effect of both changes is the same: files written from Windows now land in the layout Btrfs would have chosen for them, instead of a valid but suboptimal fallback. The driver also got refactored to use the same struct and constant definitions as the Linux implementation, which is the sort of housekeeping that pays off over the next several releases rather than this one.
There is one regression, and the author names it plainly. The improved handling of removable devices means RAID is no longer supported on them. That is a niche configuration, but if you were running a multi device Btrfs array across removable drives on Windows, test before you upgrade.
The Claude credit, and why the wording is worth noticing
The release note thanks Anthropic, whose gift of a free Claude Max subscription under the Claude Open Source Programme "helped greatly" with bug hunting and code review, and then states that all of the code in the release was still written by hand.
That distinction is doing real work right now. The Linux kernel is currently absorbing a flood of generated patches and generated bug reports, to the point where maintainers are orphaning drivers nobody has hardware for partly to reduce the surface that has to be triaged. A single maintainer using a model as a reviewer and a bug hunter, while keeping authorship of the code, is close to the opposite pattern: the machine reads and the human writes. For a filesystem driver, where a wrong write path corrupts data that a user may not check for months, that is the ordering that makes sense.
Who should upgrade, and when
Anyone writing to Btrfs from Windows should take 1.10, and should take it before the next time they write to a snapshot. Anyone using WinBtrfs read only for occasional recovery can take it at leisure, though the removable device handling improvements are worth having in exactly that scenario. ReactOS users get this indirectly, since WinBtrfs is what backs Btrfs read and write support there, and ReactOS 0.4.16 has been moving quickly on its own.
Builds are published on GitHub for x86, amd64, arm and aarch64. The one piece of homework is the scrub: if you have been writing to snapshots on the old driver, the upgrade fixes the bug but does not repair what the bug may already have done. Btrfs will tell you, if you ask it from the Linux side. It has never been the filesystem that stays quiet about its own metadata, which is part of why people trust it with snapshots in the first place.
Sources and further reading
- WinBtrfs 1.10 release, maharmstone/btrfs on GitHub, September 1, 2026
- WinBtrfs changelog, README, maharmstone/btrfs
- WinBtrfs 1.10 Released With Two Years Worth Of Improvements For Btrfs On Windows, Phoronix, September 1, 2026
Frequently asked questions
What is WinBtrfs and who needs it?
WinBtrfs is a kernel mode filesystem driver by Mark Harmstone that gives Microsoft Windows read and write access to Btrfs volumes, working on Windows XP and newer. It matters in two situations. The first is dual boot, where a Windows install and a Linux install share a data partition and you would rather not keep two copies of everything. The second is recovery, where a Linux machine will not boot and the only working system in the room runs Windows. It is also the code ReactOS uses for its own Btrfs read and write support, so the audience is wider than the download count suggests.
What is the single most important fix in 1.10?
Extent tree corruption when writing to snapshots. Everything else on the list is a crash, a hang or a missing feature, and those announce themselves. Silent corruption of the extent tree does not: it damages the structure that records which extents belong to which file, and you may not discover the damage until a scrub or a read of an old file returns something wrong. If you have been writing to Btrfs snapshots from Windows on 1.9, upgrade first and run a scrub from Linux second, before you assume the volume is healthy.
Why did it take two and a half years?
The project is essentially one maintainer working on a Windows kernel driver for a filesystem that is developed on Linux, which is a demanding combination. Version 1.9 shipped in March 2024 and 1.10 on September 1, 2026. The release note credits Anthropic's Claude Open Source Programme, which provided a free Claude Max subscription, as having helped considerably with bug hunting and code review. The same note is explicit that all of the code in the release was still written by hand, which is a distinction worth reading carefully at a moment when the Linux kernel maintainers are drowning in generated patches.
What is the regression I should know about?
RAID is no longer supported on removable devices. The change is a direct consequence of the improved handling of removable media in this release, and the author flags it explicitly in the changelog. If you were running a multi device Btrfs array across removable drives on Windows, which is an unusual configuration but not an impossible one, test before you upgrade rather than after. Multi device volumes on fixed disks are unaffected, and in fact get a fix for their disk usage statistics.
What new write capabilities does 1.10 add?
Two, and both close gaps where the driver could previously read a structure but not produce one. WinBtrfs can now write free space bitmaps, the compact representation the free space tree uses when a block group is fragmented enough that extent records become wasteful. It can also write compressed inline files, meaning small files stored directly inside their metadata item rather than in a separate data extent. Reading both was already supported, so the effect is that volumes written from Windows now look more like volumes written from Linux, instead of quietly degrading to a less compact layout.