> Using sixty threads to write 2GB files at once using 64KB writes, results in 1099MBytes/s at 0.06ms service time.
It's not a good idea to scale disk writes using threads when you can use aio. You've introduced unneeded scheduling and locking penalty from threads. Additionally, such threads will be accessing and modifying kernel structures frequently and that's going to cause additional locking inside the kernel. They'll all be modifying same resources and structures while writing.
Using async write I/O wouldn't allow them to test the capabilities of the underlying hardware as writes would return immediately.
Also, sixty threads on such a powerful machine is not really a big deal. Even though 0.06ms service time seems small, it is large enough such that you won't have more than a handful of threads competing for CPU resources (they'd waiting for some I/O completion)
The point you should take away from this benchmark is that a 3 year old Centos 5 kernel with no tuning, no filesystem tuning and default mdadm options did 100K IOPS or 1GByte/sec pretty much regardless of the benchmark options in use. It just needed enough concurrency to load up the disk. There are many other options on iozone for using different variants of posix IO and threading. I showed the basic options and the mmap option. So with careful tuning you could do IOPS more efficiently, but what I found was very accessible out-of-the-box performance.
> It's not a good idea to scale disk writes using threads when you can use aio
Last I checked (at least a couple of years ago admittedly) glibcs POSIX aio_* implementation was implemented using threads despite kernel support for it.
It is better in the sense that it is actual AIO. Whether you want AIO so badly that you're willing to suffer the lack of docs is a case-by-case decision.
TL;DR
What follows is a more detailed explanation of the benchmark configuration and results. TL;DR is short for "too long; don't read". If you get all the way to the end and understand it, you get a prize...
I sure they meant "too long; don't read" to fall in line with their "prize" of coming to interview if you could make sense of the explanations and benchmarks.
It's not a good idea to scale disk writes using threads when you can use aio. You've introduced unneeded scheduling and locking penalty from threads. Additionally, such threads will be accessing and modifying kernel structures frequently and that's going to cause additional locking inside the kernel. They'll all be modifying same resources and structures while writing.