Writing to volume hangs after some time about btrfs HOT 28 CLOSED

BTRFS Log is attached. DebugView log file was empty, alas. No messages were generated during the hanging process, however.

There are three sessions in the BTRFS log:

The first one is with DebugLogLevel set to 3. This crashed / hung Explorer in a bad way and I needed to temporarily disable the driver via a commandline boot to be able to get to a working install again. Note that I did not get to copying to the volume.

The second one is a session with DebugLogLevel set to 2. I did copy files here and I did experience the hanging behaviour.

The third one is a session prior to me uninstalling the btrfs driver (for now).

Final addition: The hanging behaviour seems to occur with larger files, although files of 10GB and up have been copied successfully to the volume.

btrfs.log.zip

from btrfs.

BTW: The readme could be a bit clearer about how to switch to the debug drivers. Just 'copy the files in Debug\x64 or Debug\x86 into x64 or x86' is not enough, as this will not replace btrfs.sys in Windows\System32\drivers.

from btrfs.

Hi, could you try the version I've just released please? It squashes a nasty deadlock bug, hopefully it's the same one!

from btrfs.

-- [deleted] --

Deletion: An extra restart did the trick to recognize the volume again. Will test later.

from btrfs.

Update:
The copying process seemed to go well initially, but at 1% of copying 1.2TB of video files the exact same issue occurred.

from btrfs.

It's slowing down then hangs
https://i.imgur.com/xm9S5Cb.png
Winbtrfs 1.0.1
windows 10 pro version 1709 build 16299.19

from btrfs.

Getting the same problem. It doesn't seem to corrupt data, it just freezes and stops being able to access the partition.

from btrfs.

This happens to me too. I have no prior experience with BTRFS and I created my BTRFS volume on an external USB disk using NextcloudPi, so it's a bit of a black box to me.
When copying my data from my Windows 10 PC to this external USB drive the copying procedure will start without a problem, but fail at any random point. It has failed before even copying a single file, it successfully copied severl Gb - I have not noticed any properties of the files that could lead to this failure.

The bigger problem is that the failed copying can lead to 1. a totally frozen Explorer.exe (even restart fails, as described earlier) or 2. a bluescreen with two possible errors (from the top of my head right now something about FAT FILE Problem and the other one I forgot - will edit once I can reproduce it at home again). This is a serious problem, because it kills my computer. Any tipps to avoid this?

I'm afraid this might happen on Linux with my RasPi, too or to loose data eventually...
Do you guys think BTRFS is ready for production and as long as I copy everything (with a bunch of restarts) I will be fine?

from btrfs.

from btrfs.

Would it help if I created logs or do you not really have time to work on the driver right now anyway?

from btrfs.

from btrfs.

I'm getting the same issue when I didn't before. I'm almost sure that is has something to do with Windows Updates either changing or removing something this driver relied on? @JSchoeck @aubade @tmteamz @dinfinity Does the issue still occur if you uninstall the driver and then reinstall it? Despite this issue being created in 2017, I feel like it has to be a issue with Window's update process.

OS: Windows 10
Ver: 1709 (Build 16299.371)

from btrfs.

@Starz0r, I think you're right - I've been able to get it to crash now, in circumstances where it definitely didn't before. My crash is caused by Windows passing a Btrfs handle to fastfat's FatFsdCleanup - I'm not sure why it'd be doing that...

from btrfs.

I'm running into this problem too. Tried copying about 70G of files from an NTFS volume to two different BTRFS volumes - hung both times after 8-10G transferred. The second btrfs volume is on a scratch drive and can be reformatted if you want me to test anything. WinBtrfs-1.0.2, Windows 10 build 17134.228 (version 1803).

from btrfs.

I am also experiencing this issue when using the latest version of it on a 64-bit Windows 10.

from btrfs.

Any news?

from btrfs.

Do anybody have a way to reliably reproduce this bug? (which I can repeat by myself)

from btrfs.

@Extravert-ir Transfer a lot of NTFS tagged files into a BTRFS formatted drive. The payload should be around 1GB or more.

from btrfs.

I wonder if this has been fixed because of the recent changes.

from btrfs.

I just tried with winbtrfs-1.1.

The first time I did a copy of 50G of assorted files and at the same time had 7zip extract an archive into the directory. The system didn't hang but after a while the FS remounted itself as readonly.

After rebooting, before I did anything interesting, I use DbgView to see a bunch of DbgPrint's that look like:
....
Btrfs ERR : insert_tree_item : error: key (14caebb6000,a9,0) already present
Btrfs ERR : insert_tree_extent_skinny : insert_tree_item returned c00000e5
....

Then I did a dd of 40G of nul's and it didn't cause any problems.

Then I did another copy of 50G of assorted files and got a few of:
....
Btrfs ERR : file_create : create_stream returned c0000022
...
but things kept on copying and finished successfully.

Then I had 7zip extract that same archive into the same place and it completed successfully.

I suspect that I stumbled on another bug, but I would be prepared to call this particular bug fixed as of 1.1.

from btrfs.

On second thought... I get the hangs eventually, just not as easily, and they're not from a sustained write that I'm intentionally doing. Haven't gotten a chance to play with DbgView to see if anything is coming out of it when the hangs happen.

So, either this bug is not fixed or there's another bug with similar symptoms.

from btrfs.

1. Open Steam, Download or verify something. (Steam uses cross-thread pipes, could cause CopyOnWrite hang problems)
2. Open Windows Explorer on drive and right click properties to force a hook because windows wants to count files.

I am running single mode on a 10 multi-drive. (Could be part of the issue?)
With these two applications open at the same time, causes a long hang and steam crashes on assert with a 'fatal stalled cross-thread pipe' on DebugView.
I'm guessing the driver's multi-access code is locking and a deadlock occurs.

from btrfs.

Are you using compression?

from btrfs.

Yes, zstd:15 compression. Does it hang because the CPU is being clogged with compression?
Though at the time, it wasn't set to use compression even though the files were originally compressed.

from btrfs.

ZSTD 15 is pretty CPU and memory intensive and I assume WinBtrfs blocks userspace until a write transaction is done; what's CPU(, RAM) and IO usage like while reproducing the bug?

from btrfs.

The few MB a second from a download shouldn't tax any compression algorithm on a modern CPU, you'd think...

I can't reproduce this on my Steam volume (two disks in RAID0). What do you mean by "single mode on a 10 multi-drive" - you've got ten disks on your Btrfs volume, but aren't using RAID? Or do you mean that your disks are exposed via some kind of underlying device?

from btrfs.

Just converted a NTFS partition of mine to BTRFS, and after copying more than 100GiB to the drive without fail, it got to a large 4GB file and then completely hung, with Explorer saying "more than one day" for the ETA. I waited several minutes before I ran Sync cause I was going to try and reboot/reset the computer and wanted to get disk caches flushed if possible, and suddenly the computer became completely responsive again and the copy continued and finished.

The directory I was copying into has Zstd compression enabled. Using WinBtrfs 1.7.5 on Windows 10 2004 64-bit

from btrfs.

Closing old issues

from btrfs.