Massive Memory Leaks while Enumerating and Updating Files in a ZFS Volume + BSOD when running KSTAT

[VykosX]

System information

Type	Version/Name
Distribution Name	Microsoft Windows 10 Pro
Distribution Version	10.0.19045 Build 19045
Kernel Version	22H2
Architecture	x64
OpenZFS Version	OpenZFSOnWindows-debug-2.3.1rc14

Describe the problem you're observing

BSOD on Windows 10 Pro 22H2 when Running Kstat and massive memory leaks observed during regular file operations with a ZFS drive, totaling hundreds of gigabytes of wasted RAM.

---

So this is a follow up to an issue I was experiencing over a year ago where the ZFS on Windows driver allocates inordinate amounts of RAM during standard operations like enumerating, comparing and updating files and never releases any of it, easily swallowing all the available memory in the system.

I've since built a new PC, a dual Xeon machine with 256GB of RAM and decided now would be a great time to try and resync my drives, which have slowly drifted apart for a over a year, since I'm using the ZFS volume as a backup drive and due to this issue I had not managed to update for quite some time as my previous paltry 32GB RAM+16GB pagefile PC would entirely die from simply trying to enumerate the contents of the ZFS drive... But unfortunately after over a year of development, it appears this issue still remains a core problem in the driver and has not been addressed.

So I decided to open another bug report in the hopes that this issue can be fixed and I can finally use my ZFS volume without it swallowing every GB of memory on my machine, as it makes my 256GB system feel like it has a measly 16GB left for anything else I want to run.

I've observed massive memory increases in task manager while enumerating files in the ZFS volume and specially when overwriting or comparing existing files between the ZFS volume and the original NTFS volume the files were replicated from. This is specially concerning because the used RAM cannot be reclaimed unless I fully reboot the system, does not appear anywhere in the process list of task manager and is never released even after the file operations are finished. Simply running WizTree to enumerate the ZFS disk or FreeFileSync with the binary comparison option enabled with a sufficient amount of large files is enough to replicate the issue on my machine.

For reference, I've originally instantiated the zpool with the following command: zpool.exe create -O casesensitivity=insensitive -O normalization=formD -O compression=zstd -O atime=off -o ashift=12 Data PHYSICALDRIVE1 using a single brand new Seagate ST18000VE002-3BS101 18TB CBR drive.

The whole reason I wanted to try ZFS out was to take advantage of the transparent ZSTD compression so I could make the most out of the usable space of my drives since NTFS compression in Windows is very poor and I have lots of small files mixed in with large ones.

I also don't know if this is relevant but the new zfs-tray app included with the recent versions of the driver does not find the Data pool, but it is however able to find a different pool that I created later with the same command. Perhaps it's because the Data pool was created earlier on an older version of ZFS on Windows? Regardless, the pool works otherwise correctly and I can import it via zpool import Data over the command line manually and export it whenever I need it, only the GUI application fails to detect it.

I was also hoping to attach a kstat dump of the system with more than half of my 256GB in use from the ZFS driver, but as soon as I ran kstat I got immediately hit with a SYSTEM_SERVICE_EXCEPTION BSOD. I thought perhaps I might be overflowing the reporting capacity of the program somehow in that instance, so I tried again after a fresh reboot and sure enough it appears that merely running the kstat software on my PC will immediately trigger a BSOD. This did not happen with the previous driver version I was using a year ago (zfs-windows-2.2.2-rc1).

So in lieu of the kstat output, I'm attaching a couple Task Manager screenshots showing the memory usage for the System and the User instead, so you can see the massive discrepancy. Also worth noting that for whatever reason Task Manager reports both my pools running on different mount points (G: and I: ) for Disk 0, but Disk 0 is only a separate pool with its own mounting point whereas the Data pool is on Disk 1 and Task Manager does not correctly associate the G: mounting point to it. I don't know how much that matters in practice, as everything else appears to work otherwise.

I humbly ask the development team to please have a look at this situation because it makes the file system borderline unusable for any serious daily usage if you intend to fill a hard drive with standard media files like videos and games.

Thank you very much and happy holidays everyone!

---

[lundman]

Excellent, it would be helpful if we can figure out which usage definitely makes it leak.. which would cut down the amount of code to inspect.

Like is it renaming dirs, files? Deleting? EA work. streams work etc.

I can fix kstat if that is broken though, will help with figuring out which bucket(s) is leaking.

[VykosX]

The three operations I noticed that cause memory leaks so far are:

1. Enumerating files. Simply selecting properties on a large enough folder or scanning the whole drive with a program like WizTree or WinDirStat is enough for several gigabytes of memory to be allocated and never returned.
2. Overwriting existing files. After synchronizing a large folder and replacing files that had changes, I had several tens of gigabytes allocated that I cant get rid of.
3. Binary comparison. This is the operation that seems to most quickly result in massive memory allocation, directly comparing the binary contents of two files with FreeFileSync to find what files should be updated instead of comparing via size and date quickly can lead the system to run out of usable memory.

As far as I can tell, renaming, deleting or creating new files does not appear to result in memory leaks.

Perhaps it would be possible to implement some kind of zpool -purge command to manually free up allocated memory until the issue has been tracked down and resolved? Because as it stands the only way to reclaim that memory is a full system reboot which is often impossible or inconvenient if you're waiting on an extended task to complete.

If you'd like me to run any further tests, do let me know! Thank you very much for your attention and work!

[lundman]

3. Can you show me the arguments used on say, a file, that you can repeat and run over and over, and it leaks?

[lundman]

kstat.exe

VERIFY3(IrpSp->Parameters.DeviceIoControl.OutputBufferLength >= sizeof (ksp)) failed (18446722698690547888 >= 18446735296499019203)

00 ffffec8f`3d95d030 fffff804`651723d9     OpenZFS!spl_panic+0x70 [C:\src\openzfs\module\os\windows\spl\spl-err.c @ 86] 
01 ffffec8f`3d95d090 fffff804`654b7f02     OpenZFS!spl_kstat_chain_id+0xa9 [C:\src\openzfs\module\os\windows\spl\spl-kstat.c @ 2237] 
02 ffffec8f`3d95d4d0 fffff804`654b6ff0     OpenZFS!ioctlDispatcher+0x822 [C:\src\openzfs\module\os\windows\zfs\zfs_vnops_windows.c @ 7903] 
03 ffffec8f`3d95d580 fffff804`cdc8e27d     OpenZFS!dispatcher+0x2c0 [C:\src\openzfs\module\os\windows\zfs\zfs_vnops_windows.c @ 8961] 
04 ffffec8f`3d95d6a0 fffff804`ce2d43a8     nt!IofCallDriver+0xcd
05 ffffec8f`3d95d6e0 fffff804`ce2d31f2     nt!IopSynchronousServiceTail+0x1c8

OK userland ksp is 0x3c0 and kernel ksp is 0x3c4. Wonder if I can make a static assert during compile time for this.

[VykosX]

I've recorded a short video of some tests on my machine showing a bunch of different ways to leak memory and I've uploaded it to Youtube for you, hopefully it makes the issues more clear!

https://www.youtube.com/watch?v=wpP7sCO0BoA

[wiesl]

Isn't just the cache filled up as you have a lot of RAM?
What happens if you copy/sync much more (in the area of your complete RAM)?
BTW: Which Hex Editor do you use?

[guenther-alka]

I also just wonder if this is not simply the expected default OpenZFS behaviour.
Unless limited in Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\OpenZFS\zfs_arc it will use up to 50% of RAM for Arc read caching and write caching. Only when another application demands RAM, OpenZFS should free RAM. This can only be a problem if the RAM demand is very dynamically and fast.

BSOD is a different item. Upload a memory.dmp for this.

[lundman]

OK arm64 work broke the mutex size, so kstat no longer matched in size.

But I am not convinced kstat works, even if it doesnt BSOD

kstat.exe.zip

[sskras]

@wiesl commented 6 hours ago:

Isn't just the cache filled up as you have a lot of RAM?

@guenther-alka commented 3 hours ago:

Unless limited in Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\OpenZFS\zfs_arc it will use up to 50% of RAM for Arc read caching and write caching.

Yes, that effect is kind of expected.

But it doesn't explain why the 1 byte change (done at 03:14 in the Youtube clip) increases the used memory by 0.6 GB (seen near 05:51) after synchronizing the changed file to the ZFS dataset.

[guenther-alka]

In a larger file, a one Byte change must read/write at least one datablock in recsize so this depends on recsize. But an increase of 600MB on a single io is at least suspicious. On the other side, you do not only use readcache for the io but also writecache (default 10% ram, max 4GB)

[VykosX]

I don't think it's just cache per se as the memory never gets released once files are closed or the operations are finished. Back when I was still had 32GB on my previous system I would routinely run out of memory entirely and the system would crash or hang. If I have a large enough operation running like syncing a whole folder, it'll quickly run out of memory even with 256GB of RAM, so I have to do everything in batches. The only way I found to release any of the allocated memory is a full system reboot.

If needed I can have OpenZFS consume essentially all but 1GB of system memory then try to run something that will forcefully allocate run to see if that will convince it to release any memory as someone has mentioned but I have the feeling it will just not work and cause the system to hang as has happened many times to me before...

Also last time I reported this in the previous thread I linked in the OP, I posted a kstat dump that showed essentially all my RAM and pagefile being consumed by OpenZFS but sadly kstat doesn't seem to work right now, so I think it's fairly safe to assume there are memory leaks in the logic somewhere.

[VykosX]

Isn't just the cache filled up as you have a lot of RAM? What happens if you copy/sync much more (in the area of your complete RAM)? BTW: Which Hex Editor do you use?

The Hex editor is called ImHex.

[lundman]

Ah heh I was adding align to the wrong part of the struct:

kstat2.zip

[VykosX]

Ah heh I was adding align to the wrong part of the struct:

kstat2.zip

I can confirm this version did not BSOD me when running it directly, I'll sync some folders to fill up the RAM and then attach a kstat dump! :)

[VykosX]

Hello! Sorry for the delay, I was syncing files across my main drive and the zfs backup volume for a couple days and I had managed to accumulate over 200GB of used memory between all the operations but unfortunately my computer froze up entirely at some point and I had to start over... So I took a few days of break before going at it again.

I'm attaching two kstat dumps, one immediately after system boot showing OpenZFS using 4GB of RAM all on its own which is about the same as the rest of my whole system combined after boot. And another after a few hours of syncing files showing about 140GB of RAM used in total, most of that from OpenZFS itself. It doesn't take long to fill up the memory at all but after around the 140GB mark or so I did notice it becomes harder to fill it, so maybe that's when it finally starts flushing memory?

Anyway I'm leaving both dumps attached for you to look into and see if they reveal anything important.

Someone did say earlier in the thread about some registry key being used to control how much memory is allocated by the driver. Could I get an explanation of how that works, and what keys should I change to change the maximum memory available for OpenZFS and how much it should allocate on boot? I want to try this again after changing those keys and see if it performs any differently.

Also, as a bonus I accidentally found another BSOD with the OpenZFS on Windows. I wanted to see if my ZFS volumes were working at appropriate speed so I ran CrystalDiskMark on them. Instant BSOD. It works fine for every other drive in my PC but if you try to benchmark the ZFS drives it immediately crashes the system. So might want to look into that as well.

Thanks everyone for their efforts I hope these problems are addressed soon!

kstat-fresh-system-boot.txt
kstat-2-hours-filesync.txt