Hi, On 28 February 2018 at 08:44, Vaughan <cxt9401@xxxxxxx> wrote: > >> The randseed is the same across different invocations of fio unless you say otherwise (see randrepeat - http://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-randrepeat >> ). So even if you weren't using a verification state file you will re-generate the same pattern if the rest of the job is the same. > Thank you for the explanation. A deep question about the seed comes:) Though randseed is the same across different invocation of fio, is it different for different sections in one job file? > I made another job file as below: > myjob.fio: > [global] > bs=4k > direct=1 > ioengine=sync > verify=crc32c > filename=/dev/sdf > io_size=10k ^^^ Note that io_size may create a potential issue - we're not necessarily going to complete a total loop (e.g. /dev/sdf is bigger than 10k) and the second job may not be aware we stopped the first job part way. In the issue you linked (https://github.com/axboe/fio/issues/468#issuecomment-332828729 ) the reporter was asking something similar (although with triggers). > [write-phase] > rw=randwrite > do_verify=0 > write_iolog=iolog > > [verify-phase] > stonewall > rw=randread > do_verify=1 > > I think these two sections have the same settings except the date direction. So I expect the later one can verify the write-phase. But it failed. > run it with --debug, and found the offset generated are not the same, so verify abort with error for the first time, as below: > random 24382 off rand 259043585 > io 24382 fill_io_u: io_u 0x25ad740: off=71233536/len=4096/ddir=1//dev/sdf > random 24382 off rand 3179521932 > io 24382 fill_io_u: io_u 0x25ad740: off=874364928/len=4096/ddir=1//dev/sdf > random 24382 off rand 3621444214 > io 24382 fill_io_u: io_u 0x25ad740: off=995893248/len=4096/ddir=1//dev/sdf > random 24388 off rand 1094293889 > io 24388 fill_io_u: io_u 0x25ad500: off=300929024/len=4096/ddir=0//dev/sdf > You can see [24382] is write-phase and [24388] is verify-phase, and the first round of them use different seed I suppose. > > I search in the source code, and found the following snippet: > static int setup_random_seeds(struct thread_data *td) > { > ... > for (i = 0; i < FIO_RAND_NR_OFFS; i++) { > td->rand_seeds[i] = seed * td->thread_number + i; > seed *= 0x9e370001UL; > } > > Is td->thread_number different for different sections? I thought they both equal to 1 before. 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. Note that because you're verifying by header and via a separate job I believe fio checks the header in the current block and if it looks intact it then uses that to regenerate the data in the rest of the block. You can get just about away with this when you're writing and verifying the entirety of the file with fixed block sizes but 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. > Later, I realize split verify using two sections in one file is not a formal way? Is it better to just write only one write section, and use 'fio --verify-only jobfile' to do the split verification as the updated one below? That does look like it will be more robust and will also allow you to use a state file if you wanted too. -- Sitsofe | http://sucs.org/~sits/ -- 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
