On Fri, Jan 28, 2022 at 6:16 PM Damien Le Moal <damien.lemoal@xxxxxxxxxxxxxxxxxx> wrote: > 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 ? I'm seeing the same behavior when I replace wait_for with stonewall. E.g., a time of just over 20 seconds for: 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 --stonewall --startdelay=5s This is also the behavior I'd expect (but not want of course) based on the code in backend.c . It's also the behavior I see when I put a single job with a start delay in a file and invoke fio with the same file twice. E.g., foo.fio with contents of: [job] ioengine=libaio direct=1 filename=/dev/nvme1n1 rw=write iodepth=16 bs=128k size=15GB runtime=10s time_based=1 startdelay=5s and then invoking time sudo fio foo.fio foo.fio gives a runtime of 25 seconds, when I'd expect 30 = (5 second wait + 10 second execution ) * 2 In most of the cases it seems like the ETA is confused by the behavior two. ETA jumps instantaneously from 15 down to 10 when the first run of foo.fio is complete and the second one begins.
