I should rephrase that, it's not "really bad" but the way that most people use it is not good. The main issue is caching from your OS, and caching from the hypervisor ( the one that runs your VM ).

There is also the problem about i/o syncing. By default OS buffer the data before writing it to disk.

That's true of all I/O benchmarks, even those which try to do things like call fsync since the lower layers often lie about whether something was committed to durable storage. The only way to do benchmarks reliably is still to make sure that you're reading/writing data which is much larger than the available cache.

In the case of dd, the real reason why it's often a misleading benchmark is that it's the best-case scenario: full-size streaming I/O where each block is only accessed once. Some applications do have that kind of operations pattern but most don't and can see very different performance characteristics because they depend on things like file creation/deletion overhead, random I/O within an open file, read and write contention if the same file is being accessed by multiple processes, etc.

probably because it can produce meaningless results. it's extremely hard to tell where which bits actually ended up, ram, or disk, or some other intermediate buffer or cache on a controller somewhere.

we use fio with a standard test config across systems for meaningful results.