Something else to bear in mind is that because you aren't using direct=1 (see http://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg- direct ) there's nothing (other than size) stopping your I/O being entirely cached in RAM thus creating unrealistically fast speeds. Worse still, there's a good chance that ZFS doesn't support O_DIRECT so you won't be able to use direct=1 even if you wanted to. To try and combat this you will have to write/read an area at least twice the size of your RAM (2 GBytes is likely too small). I know you get fast SSDs but doesn't 3GByte/s seem unusually high? :-) The usual telltale sign that your I/O is being cached in RAM is that the minimum latency is 0ms - if you ever see that you will know you're suffering/benefiting from OS caching.
You also need to look at the contents of a file after fio does randwrite rather than its preallocation. It's worth pointing out your blocksize is giant at 512k and you went for a slightly poorer but computationally cheaper random number generator and turned off hitting every block once. I have to admit I'm baffled as to why a later fio would perform differently but as you suggest perhaps it's down to a bug that has been fixed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1703440 Title: xenial fio 2.2.10 randwrite: "random" data NOT random, highly compressible -> highly misleading output To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fio/+bug/1703440/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
