maharmstone
System freezes when writing to disk
When data is written continuously (it has happened to me when installing games) after a while the writing stops and explorer.exe freezes and it is not possible to restart the process, causing problems throughout the system. A force shutdown is necessary, because if you use manual reboot normally, the system will freeze at the Restarting message and the system will never reboot. Without any problem in Linux performing exactly the same writing tasks.
My system: Windows 11 23H2 SSD SATA III 1TB Silicon Power A58 with SLC Cache AMD Ryzen 5 4600G RAM Corsair 16 GB DDR4-3200 Dual Channel Nvidia GTX 1650 Motherboard MSI A520M-A PRO
Are you sure you are using the latest version 1.9? I had this problem before version 1.9 and updating fixed it. Maybe you could also try reinstalling the driver if you're running the latest version.
Reinstalling making sure I was installing the latest version did not work to fix the problem. :( I'm using a recent clean install of Windows, no weird extra installs or debloat of any kind. I thought there might be an issue with the disk, but on Linux it works normally.
Same thing just started happening to me too. Disk works fine in Linux but extended writes are causing Explorer to freeze. After some time Explorer will restart and stuff will work again for a few seconds. Wondering if it's something with a recent Windows update.
Win11 23H2 22631.3447 WinBtrfs 1.9
It happens to me with the latest version. But the problem is less recurring if you set Windows Power to "High Performance" in the Control Panel. Now it only hangs for a few seconds. The task manager shows response time 99999ms and Disk usage 100% even though it is reading and writing 0
It also happens if you delete many files with the "Permanently Delete" option
I run into the same issue on WinBtrfs 1.9. it tends to also happen when some games are loading
This is happening to me, especially when I use the drive in Steam and it tries to patch a big update like Ark update which is more than 40 Gigabytes. The drive becomes unresponsive multiple times during the write (heavy write) and then suddenly stops working, it does not allow even the Windows to restart and the whole Windows becomes unresponsive, the only way is to force shutdown by holding the power button for 15 seconds and turn it on again.
I use 2TB KC3000 PCIe 4.0 NVMe M.2 with Windows 11 Pro 24H2 and driver version 1.9.
I've been having this issue, too. It only started happening after I moved my Btrfs drive to my new PC. My old PC was running version 1.8.2, new one is running 1.9. I tried downgrading it to 1.8.2, but it still happens regardless. My old PC was on Windows 11 23H2, new one is on 24H2. The drive in question is a WD Blue 1 TB hard drive.
Maybe this has to do with the low free space remaining on the file system?
I experienced something similar after my 38.68 GB volume got filled with only 1.99 GB remaining free. Now every time I try to copy in a larger file, the I/O gets stalled. A reboot is needed to fix that.
The exact numbers:
B:\> wmic logicaldisk where "name='B:'" get volumename,size,name,filesystem,freespace
FileSystem FreeSpace Name Size VolumeName
Btrfs 2137743360 B: 41527803904 A Btrfs Vol
My excuses if that's another issue.
Maybe this has to do with the low free space remaining on the file system?
It's unrelated. I have about 1TB free on a 2TB drive, and the problem still occurs.
I'm also encountering this issue on Windows 11, version 1.9. Brand new install, brand new m2 SSD. btrfs drive separate from boot drive. Played a game with another game downloading in the background and would get ~30sec freezes every few minutes. Download was going at around 40MB/s.
Sorry if my input is useless. I'm not involved in the actual development of the driver, but each time I here a response on this topic it feels like it is either a windows scheduling issue with a weak chance of efficiently fixing because of the cursings of Microsoft, or an issue with the packet (right term?) queueing. The units that get written have to interact with Microsoft's nonblocking, nonlinear capabilities, so something might be getting caught either with a a queue link array overflow, or a timer not being set correctly? I'm sure me commenting when I don't know the internals of the driver will be of little use, but I wish to help. Please ignore me if I'm way off. It just seemed to me like the thread was exposing something significant and there were no leads...
On Fri, Jul 18, 2025, 18:19 Michael Chen @.***> wrote:
blorbx left a comment (maharmstone/btrfs#660) https://github.com/maharmstone/btrfs/issues/660#issuecomment-3091297722
I'm also encountering this issue on Windows 11, version 1.9. Brand new install, brand new m2 SSD. btrfs drive separate from boot drive. Played a game with another game downloading in the background and would get ~30sec freezes every few minutes. Download was going at around 40MB/s.
— Reply to this email directly, view it on GitHub https://github.com/maharmstone/btrfs/issues/660#issuecomment-3091297722, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGJF6KP4MMMQMI2OJAVPT33JGFJRAVCNFSM6AAAAABHXFNAG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOJRGI4TONZSGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I'm also encountering this issue on Windows 11, version 1.9. Brand new install, brand new m2 SSD. btrfs drive separate from boot drive. Played a game with another game downloading in the background and would get ~30sec freezes every few minutes. Download was going at around 40MB/s.
This is happening to me, especially when I use the drive in Steam and it tries to patch a big update like Ark update which is more than 40 Gigabytes. The drive becomes unresponsive multiple times during the write (heavy write) and then suddenly stops working, it does not allow even the Windows to restart and the whole Windows becomes unresponsive, the only way is to force shutdown by holding the power button for 15 seconds and turn it on again.
I use 2TB KC3000 PCIe 4.0 NVMe M.2 with Windows 11 Pro 24H2 and driver version 1.9.
Same here. Fresh install of Fedora 42. Had the great idea to share my Steam library between Windows and Linux.
Guess not.
I'm confused as I thought the freezes during writes were fixed in 1.9 ? It may not be useful but it seems the freezing only occurs when mass writings (50GB+) is happening and as of 1.9 it seem to only occur on Windows 11 systems for us and we didn't encounter it on Windows 10 since 1.9
@DippyFoxDerg commented last week:
with the amount of people encountering this issue, me included, im really surprised there has not been a patch for it.
It's all about the manpower of dissecting FS level bugs, which usually are pretty hard due to the very complex environment (which NT kernel is).
@Gemeinagent commented last week:
Same here. Fresh install of Fedora 42. Had the great idea to share my Steam library between Windows and Linux.
At least if you could install OpenZFS on Windows and on Fedora, this might allow for a temporary workaround.
Looks like the v2.3.2 support was added for F42 on May 3, 2025.
The latest Windows port seems to be v2.3.1, namely OpenZFSOnWindows-debug-2.3.1rc10v3.exe released on Aug 7, 2025.
any temporary workaround to this i have a btrfs HDD drive and it has a lot of files i wanna move them to an ntfs drive and format the hdd to ntfs but it keeps freezing
I'm also encountering this issue on Windows 11, version 1.9. Brand new install, brand new m2 SSD. btrfs drive separate from boot drive. Played a game with another game downloading in the background and would get ~30sec freezes every few minutes. Download was going at around 40MB/s.
This is happening to me, especially when I use the drive in Steam and it tries to patch a big update like Ark update which is more than 40 Gigabytes. The drive becomes unresponsive multiple times during the write (heavy write) and then suddenly stops working, it does not allow even the Windows to restart and the whole Windows becomes unresponsive, the only way is to force shutdown by holding the power button for 15 seconds and turn it on again. I use 2TB KC3000 PCIe 4.0 NVMe M.2 with Windows 11 Pro 24H2 and driver version 1.9.
Same here. Fresh install of Fedora 42. Had the great idea to share my Steam library between Windows and Linux.
Guess not.
It only works if you do some specific steps and leave everything mostly default.
- format Btrfs from Linux (for gosh sake, don't use format from winbtrfs)
- from Linux, use sudo chmod 777 /path/to/the/game/directory
If you want, apply very low level compression (lzo level 1), but honestly you can leave it default.
- on Windows, use WinBtrfs with or without compression. Do not disable Copy-on-Write (CoW) as there is an issue with WinBtrfs.
After these steps, I haven't gotten any specific issues (beside of course some games not running on Windows like EA F1 25 or Game Pass games, but that's a Windows "issue" since there are anti-cheats and other blockers that you might - or not - bypass by using virtual disks formatted with NTFS).
I've also tried ext4 with Paragon's driver, but Steam games refuse to install on Windows with ext4 partition. UDF has horrible performances. The only alternatives are:
- NTFS (with symlinks and adjustments on Linux, you'll have to use a bit of space on Linux)
- exFAT (with particular adjustments in the fstab files, since you can't use symlinks, and still using some space)
- UDF (terrible performances)
- btrfs (some issues, but mostly works as default beside some anti-cheat solutions from EA or Game Pass)
NTFS and WinBTRFS are those that worked better for me.
Sorry if my input is useless. I'm not involved in the actual development of the driver, but each time I here a response on this topic it feels like it is either a windows scheduling issue with a weak chance of efficiently fixing because of the cursings of Microsoft, or an issue with the packet (right term?) queueing. The units that get written have to interact with Microsoft's nonblocking, nonlinear capabilities, so something might be getting caught either with a a queue link array overflow, or a timer not being set correctly? I'm sure me commenting when I don't know the internals of the driver will be of little use, but I wish to help. Please ignore me if I'm way off. It just seemed to me like the thread was exposing something significant and there were no leads... @…
I'm also experiencing the issue with plain btrfs on linux. Which leads me to think that this is an upstream btrfs issue.
It happens to me as well. A workaround so far is to disable compression via registry.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\btrfs]
"Compress"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\btrfs\<GUID>]
"Compress"=dword:00000000
After changes in the registry, reboot.
This way, mounted without compression, I don't have the issue. Maybe it still happens with even heavier write operations, not sure.
