On 1/29/22 02:02, Nick Neumann wrote: > On Wed, Jan 26, 2022 at 5:41 PM Damien Le Moal > <damien.lemoal@xxxxxxxxxxxxxxxxxx> wrote: >> The job that needs to be started after a delay should have both wait_for and >> startdelay options. That should work. > > So that's what I expected and hoped. But it doesn't seem to work that > way. For example, I tried this: > > time sudo fio --ioengine=libaio --direct=1 --filename=/dev/nvme1n1 > --rw=write --iodepth=16 --bs=128k --name=job1 --size=15GB > --runtime=10s --time_based --name=job2 -size=15GB --runtime=10s > --time_based --wait_for=job1 --startdelay=5s > > The first job runs for 10 seconds writing. The second job does the > same but both waiting for job1 to complete, and with a startdelay of > 5s. So I would expect the total command to take about 25 seconds = 10s > job 1 + 5s startdelay for job2 + 10s job2 . But instead the startdelay > appears to begin counting when fio begins, not when job2 becomes > eligible to run due to job1 completion. The output for the runtime of > the command above is 20.760s, with the second job starting immediately > when job1 completes. OK. There may be a bug then, startdelay is not accounting for the fact that the wait_for option is being used. Can you try the stonewall option instead of wait_for ? -- Damien Le Moal Western Digital Research
