-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fio 3.33 report Invalid or incomplete multibyte or wide character #1517
Comments
Environment: fio version: Reproduction steps: it will report a error shortly fiofiotest: (groupid=0, jobs=1): err=84 (file:io_u.c:2190, func=io_u_queued_complete, error=Invalid or incomplete multibyte or wide character): pid=494472: Tue Feb 14 13:04:34 2023 Run status group 0 (all jobs): Disk stats (read/write): |
but if use "-verify_async=4 --verify_backlog=8" parameter, it will run normally |
use below paramter,(-verify=md5, and without '-verify_async=4 --verify_backlog=8'), it still report error |
so the conclusion is
|
I've root-caused this issue. The random seed used to generate the data pattern for writes is getting out of sync with the reuse of that same seed for the verifies. Here's the flow:
Lines 1236 to 1259 in 1bd16cf
Lines 1035 to 1038 in 1bd16cf
Lines 640 to 647 in 1bd16cf
There is already logic in Lines 920 to 925 in 1bd16cf
Note There are multiple ways to fix this. One would be add write-only workloads as a case to ignore the random seed, although that weakens the integrity checking of the verify logic. Another way would be to regenerate the random seed for each iteration of |
just wonder if fio with "-verify_async=4 --verify_backlog=8" (and with other parameters) can do verification rightly as expected? |
|
Thank you. |
Verify fails with "bad header rand_seed" when multiple iterations of do_io() execute (time_based=1 or loops>0), with verify enabled and randrepeat=0 The root cause is do_verify() resetting the verify seed back to the job-init value, which works for verification of the first iteration of do_io() but fails for subsequent iterations because the seed is left in its post-do_io() state after the first do_verify(), which means different rand values for the second iteration of do_io() yet the second iteration of do_verify() will revert back again to the job-init seed value. The fix is to revert the verify seed for randrepeat=0 back to ts state when do_io() last ran rather than to its job-init value. That will allow do_verify() to use the correct seed for each iteration while still retaining a per-iteration unique verify seed. Link: axboe#1517 (comment) Signed-off-by: Adam Horshack (horshack@live.com)
@xirs, This fix for this issue has been merged. Can you please verify and close this issue? Thanks. |
I have downloaded master branch and compiled fio binary, and will try it |
I use below command, and it won't report error now. |
Verify fails with "bad header rand_seed" when multiple iterations of do_io() execute (time_based=1 or loops>0), with verify enabled and randrepeat=0 The root cause is do_verify() resetting the verify seed back to the job-init value, which works for verification of the first iteration of do_io() but fails for subsequent iterations because the seed is left in its post-do_io() state after the first do_verify(), which means different rand values for the second iteration of do_io() yet the second iteration of do_verify() will revert back again to the job-init seed value. The fix is to revert the verify seed for randrepeat=0 back to ts state when do_io() last ran rather than to its job-init value. That will allow do_verify() to use the correct seed for each iteration while still retaining a per-iteration unique verify seed. Link: axboe#1517 (comment) Signed-off-by: Adam Horshack (horshack@live.com)
Please acknowledge the following before creating a ticket
Description of the bug:
Environment:
fio version:
Reproduction steps
The text was updated successfully, but these errors were encountered: