Read/write speeds in RAM Disk vs RAM FS

On my configuration, the RAM FS seems to have very significantly improved single queue reads/writes, with significant improvements in random reads/writes, but has given up some ground on large sequential multi-queued reads/writes.

The test bed is running DDR4 in quad channel at 1600 MHz.

I would expect that to be a significant improvement on standard workloads.

Thanks for sharing your results!

In our testing we've found there's quite a bit of variation between runs and even between reboots, especially in the 1 MB tests that are limited by memory bandwidth. Those tend to fluctuate depending on the overall system load and whatever else is running in the background at the same time.



There are also a few areas where RAM FS is noticeably faster for reasons that don't show up in bandwidth benchmarks. For example, file creation and deletion are generally faster. It also supports reflinks, which NTFS doesn't. If you copy a 1 GB file within one RAM FS volume, the copy is created instantly and uses virtually no additional memory until either copy is modified (this requires Windows 11 24H2 or above).

I'm seeing some odd results with RAM FS. It's a lot faster than RAM Disk, as expected, in all but one case — the RND4K/Q32T6 write test.

RAM Disk and RAM FS are both installed on the same machine, and the tests were performed multiple times, one after the other. I consistently get a lower score (compared to RAM Disk) in this particular test.

The RAM FS version is 26.8.1.

I uninstalled RAM Disk and repeated the test, but the result was the same.

Thank you for the detailed report, and especially for the side-by-side screenshot - that made the cause identifiable straight away.

What you're seeing is almost certainly Windows Defender's file system filter, not a limitation of RAM FS. We ran into exactly the same thing during development: on a volume that isn't in Defender's exclusion list, the filter can take an exclusive lock on every write, which serialises all concurrent writes. We confirmed it with a kernel debugger - the benchmark threads were all blocked inside Defender's filter while our own write path was completing in microseconds.

That matches your results precisely: reads are unaffected (your Q32T16 read beats RAM Disk), single-threaded writes are unaffected (2822 vs 1842 — RAM FS is faster), and only the multi-threaded write collapses. Most tellingly, your 16-thread write result is about three times slower than your own single-threaded one — adding threads makes it go backwards, which is the signature of lock serialisation rather than any throughput limit. RAM Disk avoids it because it presents an ordinary NTFS volume, which Defender recognises; RAM FS is a file system in its own right, so the filter treats it more conservatively. That's also why uninstalling RAM Disk changed nothing.

Could you try this? In an elevated PowerShell:

Add-MpPreference -ExclusionPath 'R:\'
Add-MpPreference -ExclusionProcess 'DiskMark64.exe'

Then re-run CrystalDiskMark. We'd expect the RND4K Q32T16 write figure to jump from ~900 MB/s to well over 10,000 MB/s, with the other results largely unchanged.

Two things worth knowing, as both caught us out:

• Turning real-time protection off is not enough - we measured the same penalty with it disabled. Only the path exclusion cleared it.
• If the exclusion alone doesn't help, please reboot and re-test. The exclusions persist across restarts, and we've seen the filter stay in this state once it has engaged on a volume - a reboot with the exclusion already in place clears it.

Everything else in your results is as expected - thank you for taking the time to run the comparison so carefully. Please let me know if it helps.

I forgot that I had CrystalDiskMark set to the "NVMe SSD" setting, which runs the test with 16 threads instead of 1.

Write speed, 1GB test file:
RND4K/Q32T16 = 922.60 MB/s
RND4K/Q32T1 = 2486.94 MB/s

So it looks like the multithreaded writes are notably slower than single-threaded writes.

Yes, please see the above - we've encountered the exact same thing in T4 and T8 tests and it turned out to be a serialisation lock in WdFilter (Windows Defender).

(Sorry, I was writing at the same time as you.)

And you are absolutely correct! The culprit is Windows Defender and multi-threaded operations.

I added R:\ and DiskMark64.exe to the exclusion list, as you suggested, and the result was quite different — i.e., what it "should" be without Microsoft's intervention... See image below.

After doing a couple of tests on my current setup, it looks like the exclusion path ("R:\" in this case) is enough. The write speeds for me are not affected by the process ex-/inclusion setting. This is good, since process exclusions are a bit more difficult to manage.

Thanks a lot for explaining and finding the cause for the slow write speeds, really great support! I'm now on the customer list for RAM File System (after ~10 years with RAM Disk )

Awesome, thank you for confirming this! Interestingly, it only happens occasionally.

Later on we'll investigate why Defender does this and hopefully find a better workaround.