[mitchellh]

You're assuming the writes are actually going to a physical disk. As I mentioned in the post, the hypervisors are very likely just writing to RAM and not ever committing it to disk. Even when you `fsync()` from a VM, there is no guarantee the hypervisor puts that to disk.

If you look at the graphs, they corroborate this. The "native" disk never really exceeds 500 to 600 MB/s, which is about as fast as my SSD goes. The hypervisors, however, are exceeding multiple GB/s. It must be RAM.

Also, re: "I'm not sure what was actually benchmarked" The method of benchmarking is covered in the bottom of the post. I realize it isn't extremely detailed. If you have any questions, I'd be happy to answer.

[wila]

The problem is that the tests are flawed and the native speed being slower as virtual is a pretty big red herring for that. That's OK because benchmarking that tests what you are after is actually very difficult. Small assumptions can create big differences. If you can't guarantee that the data has actually been written to the disk then you're testing caching mechanisms, something you already point out in your article, but then you're no longer testing file system performance as the article claims it is benchmarking. The problem is that we don't even know which caching mechanisms (guest OS, hypervisor, hard disk driver) or that the conditions are always the same.

A typical thing that performance benchmarks do to negate guest OS caching is to process significantly more data as what the available RAM is set to. For example, if your guest OS RAM is set 512MB, process 10GB of random data. Of course then the question is how-to get random data as you don't want to end up testing the random generator ;) or your host OS caching.

Another way to make sure you test data committed to disk could be to include a "shutdown guest OS" part and measure total time until the guest has been fully shut down.

I know that at least VMware has the ability to turn off disk caching (in Fusion, select Settings, advanced "Hard Disk Buffering" <- disable). I am not aware of a similar feature in Virtual Box, it might exist though.

Even while you tested the same guest OS, we don't even know if the hard disk adapters where both using the same hard disk drivers. Performance differs between IDE/Sata/SCSI drivers. SCSI drivers have queue depths, IDE drivers have not.

[mitchellh]

While the article uses only 64 KB/MB files for the analysis, the full Excel workbook contains data that had up to 512 MB files. The VMs only had 256 MB of RAM, so I did indeed test the RAM-spillover cases. The results were very similar, though unsurprisingly the VMs didn't perform quite as well (though they did still beat over native).

I never tested going over the native's RAM.

[jamesaguilar]

The amount of memory allocated to the vm does not include the host fs cache. So it is still easily possible for a 500M file to fit in that.

[weddpros]

I meant to say you've not benchmarked disk access, and we have no idea what each filesystem is actually doing. Caching performance is "nice", but it says nothing about the actual performance we'd get in real use. Maybe the "slow" fs just exhibits less aggressive caching, which might prove just as efficient depending on the workload. It's definitely interesting to note the huge differences, but I'd really like to see how it goes in "real" conditions...

[hnriot]

how are these not real conditions?

[buster]

I don't know what you are doing in real conditions but i am for sure not only running everything in my RAM (that'd be great, i wouldn't even need a harddisk anymore). The benchmark needs to be revised to account for the VM caching or it's just useless. Or rename it to "benchmark of memory access and caching algorithms".