> It looks that way - it seems like thread_number is incremented for each job in > get_new_job() so this would affect the random seeds generated in different sections of the same job file. > I think what you've pointed out will make jobs like: > > fio --stonewall --verify=crc32c --size=24k --bsrange=512-4k --filename=/tmp/fio.tmp --name=write-phase --rw=randwrite --do_verify=0 --name=verify-phase --rw=randread --do_verify=1 > > fail because the random ordering of block sizes now depends on the job number too. Yes, I agree with you. So the right way should be verify it with the original write jobfile and appending "--verify_only". Can you further explain the usage of --verify_state_save --verify_backlog --verify_backlog_batch options? I need to split verify tera-byte size of data. According to the HOWTO of fio to avoid memory exhaustion, verify_backlog should be used. so I do the write job with "--verify_state_save=1 --verify_backlog=1 --verify_backlog_batch=10240" in cmd line and do a split verify by appending "--verify_only" with the same write command options. But it seems it just verify the 10240 ios, not the same size as write job. Only if I verify without "--verify_state_save=1 --verify_backlog=1 --verify_backlog_batch=10240", it verify the whole size I write. I get the conclusion by run the write work and verify work with "write_iolog=str" and compare the iolog, and also "ios=" in "Disk stats" section of both fio output. Another question about write process with "rw=randwrite" and "bsrange=". If run it with "ioengine=libaio iodepth=16", will this async write get any overlap? Thanks, Vaughan -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
