Additional fio block sizes about yet-another-bench-script HOT 5 CLOSED

Thanks for the suggestion. I'll look into this a bit and do some testing to see if it'll be beneficial. Most likely would be implemented as a flag if I decide to bake it in. I've been wanting to clean up the disk test code anyway, so this might give me a good opportunity to do so.

from yet-another-bench-script.

Is there any chance that the tests done after 4kb are cached in any way? If I test this script vs bench.sh or MonkeyTest, I don't see as fast of a speed with the others as I do with fio.

from yet-another-bench-script.

No, fio doesn't cache results and does non-cached random writes/reads for every test. I'm not familiar with MonkeyTest, but bench.sh does sequential disk speeds which are often way different than random read/write tests. SSDs/NVMe drives often do rather poorly on sequential tests and very well on more real-world tests (random read/writes).

from yet-another-bench-script.

@camjac251 so after testing this on and off the past couple months, I haven't really seen any instances where using higher block sizes than the highest default size (1mb) results in any significant speed boost, either on nvme, ssd, or spinning rust drives. So with that I'm not sure it's worth adding an option into the script to use higher block sizes as it won't really be beneficial for most people.

Have you tried testing with the fio utility yourself to see if you see any significant difference in throughput when doing really large block sizes? I'm curious what behavior you're seeing with large block sizes like that.

from yet-another-bench-script.

Closing pending further discussion.

from yet-another-bench-script.