You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After running into 2 situations where I don't/can't get the requested iodepth I've been meaning to find a succinct explanation of what this actually represents - and a quick search just now came up empty both in the manpage and here.
KDiskMark calls them "queues", which makes me think they're something like parallel operations except in a single thread, but I've been known to be very wrong.
One reason I'm interested is that I've been tinkering with KDiskMark, and rather than let it tell fio to do impossible things (and possibly get garbled json output back) I do an on-the-fly verification and possible correction of the intended iodepth. That still means the user gets a different result than asked for, but at least it's a valid result that corresponds to the reported corresponding test parameters. It also means that there may be multiple identical tests - KDiskMark uses profiles that are based on those used by CrystalDiskMark, and those involve pairs of tests with a given block size and 2 iodepths - of "N" and of "1".
So, and this may sound naive, if there's any way to scale down the iodepth and scale up the block size that could be expected to give roughly comparable test results, that could be a smarter form of adapting the test than simply capping the iodepth...
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Hi,
After running into 2 situations where I don't/can't get the requested
iodepthI've been meaning to find a succinct explanation of what this actually represents - and a quick search just now came up empty both in the manpage and here.KDiskMark calls them "queues", which makes me think they're something like parallel operations except in a single thread, but I've been known to be very wrong.
One reason I'm interested is that I've been tinkering with KDiskMark, and rather than let it tell fio to do impossible things (and possibly get garbled json output back) I do an on-the-fly verification and possible correction of the intended iodepth. That still means the user gets a different result than asked for, but at least it's a valid result that corresponds to the reported corresponding test parameters. It also means that there may be multiple identical tests - KDiskMark uses profiles that are based on those used by CrystalDiskMark, and those involve pairs of tests with a given block size and 2 iodepths - of "N" and of "1".
So, and this may sound naive, if there's any way to scale down the iodepth and scale up the block size that could be expected to give roughly comparable test results, that could be a smarter form of adapting the test than simply capping the iodepth...
All reactions