I think you’re comparing apples with oranges here.
First off, the benchmark is a bit flawed for two reasons:
- cache=none actually still has a disk cache on the guest end.
- The guest OS is already performing its own caching and such, therefore having a caching system running on top of a caching system isn’t very useful.
Here’s the bigger issue though: if you read through that thread, you’ll actually see that O_DIRECT, if implemented, would do absolutely nothing. The proposal was to have it be accepted but be a noop, vs the current situation where any calls that use O_DIRECT on a tmpfs file will fail.
The reason for this is that the purpose of O_DIRECT is to bypass the page cache while working with files. However, a tmpfs itself lives inside the page cache, so there’s nothing that can be bypassed. Therefore, O_DIRECT on a tmpfs can’t really do…anything. As the Debian wiki describes ramfs/tmpfs:
Basically, you’re mounting the disk cache as a filesystem.
It’s hard to say why you’re seeing a performance difference, but some guesses:
- You didn’t specify what you’re using to benchmark it on Linux, and I’m guessing it’s not CrystalDiskInfo. Different tools may have different ways of manipulating the ramdisk, thus it’s hard to perform an accurate comparison here.
- ImDisk may store files in a different area of RAM without relying on a cache implementation. Therefore, direct I/O performance (not sure how CrystalDiskInfo benchmarks, but I’m guessing it tries to bypass caches) will be faster…but general-purpose use will be slower because you have the Windows page cache running on top. That results in more back and forth copying in RAM, vs Linux’s implementation where the page cache is the tmpfs.