Hi,
--
On 28 July 2018 at 14:26, Jeevan Patnaik <g1patnaik@xxxxxxxxx> wrote:
Hi,
Is Iodepth of fio and queue depth of storage both same? Then, how is it possible to control queue depth with an iodepth parameter from fio
fio iodepth and the depth I/O your OS achieves submitting I/O down to storage are linked but most certainly do not have to be the same and the relationship is highly dependent on your operating system/storage/fio ioengine used/fio parameters. Basically fio submits I/O a particular way to your operating system. Depending on how you submit your I/O to your operating system it can choose to submit it further down in a more optimal/different fashion (e.g. by batching requests together, breaking requests that are too big into smaller pieces, delaying I/O etc). Additionally and as stated in the HOWTO (http://fio.readthedocs.io/en/latest/fio_man.html#cmdoption-arg-iodepth ), iodepth only affects asynchronous ioengines (and note that text includes warnings about the need to use direct=1 on Linux).
command? Will that be creating parallel jobs, but then again there is an option to run jobs in parallel also (will that not be a trivial or conflicting?)
I'm going to give a brief summary but note I'm not trying to cover caching/readahead/plugging/block device layers (e.g. RAID/LVM) etc:
A synchronous fio I/O engine submits a single I/O to the OS, waits for it to be "acknowledged" as having been received and then sends another I/O etc.
If an fio I/O engine is able to submit I/O to the OS in a truly asynchronous fashion (see link above) then the key is that it does NOT have to wait for earlier I/O to be "acknowledged" before submitting new I/O. If the iodepth is only 1 it will have to behave in a fashion similar to a synchronous I/O engine. However, let's say a jobs specifies an iodepth of 32. In that case up to 32 I/Os to be outstanding before fio will choose to wait before submitting any more I/O (just what the watermarks are and how much is submitted at a time is controlled by the iodepth_batch_* options. This can be more efficient and achieve higher throughputs but often comes with a cost of higher latency.
fio will not create parallel *fio jobs* just because of iodepth BUT using parallel fio jobs is another way of increasing the amount of simultaneous I/O being submitted at any given time (by using different threads/processes) and using both on the same device will act in tandem (so if you have two fio jobs submitting asynchronous I/O at an iodepth of 16 each your OS could be be actually receiving 32 I/Os at any given time). There can be reasons for combining the two (e.g. you have multiple devices and they are so fast that one CPU can't keep up even when submitting I/O asynchronously).
I am struggling to understand how fio is controlling it's workloads (especially about this iodepth). Can someone please explain the iodepth parameter in detail.
I will note you've also asked this question over on stackexchange (https://unix.stackexchange.com/questions/459045/what-exactly-is-iodepth-in-fio ). You may want to link to https://www.spinics.net/lists/fio/msg07190.html from there to help others who may have a similar question...
Sitsofe | http://sucs.org/~sits/
