For read jobs, users should have the option to verify header seeds at a
later point of time. Currently for read jobs header seeds are not
generated
Consider the below mentioned write followed by read workloads. Here fio
should allow header seed verification.
fio --name=test --filesize=16k --rw=randwrite --verify=md5
fio --name=test --filesize=16k --rw=randread --verify=md5 --verify_header_seed=1
However there are other scenarios where header seed verification will
fail. These include:
* randrepeat is set to false, leading to different seed across runs.
* randseed is different across write and read workloads.
* Read workload is changed from sequential to random or vice versa
across runs.
* Read workloads run in the same invocation as write, i.e. a write job
followed by a stonewall read job. Header seed verification will fail
because random seeds vary between jobs. Refer t/jobs/t0029.fio
If verify_header_seed is explicitly enabled, fio will verify header seed
for the workload.
This reverts part of commit mentioned below
Fixes: def41e55 ("verify: decouple seed generation from buffer fill")
Signed-off-by: Ankit Kumar <ankit.kumar@xxxxxxxxxxx>
---
HOWTO.rst | 16 ++++++++++++----
backend.c | 11 +++++++++++
fio.1 | 15 +++++++++++----
3 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/HOWTO.rst b/HOWTO.rst
index 05bdeebb..6d462af3 100644
--- a/HOWTO.rst
+++ b/HOWTO.rst
@@ -3907,10 +3907,18 @@ Verification
:option:`ioengine`\=null, not for much else.
This option can be used for repeated burn-in tests of a system to make sure
- that the written data is also correctly read back. If the data direction
- given is a read or random read, fio will assume that it should verify a
- previously written file. If the data direction includes any form of write,
- the verify will be of the newly written data.
+ that the written data is also correctly read back.
+
+ If the data direction given is a read or random read, fio will assume that
+ it should verify a previously written file. In this scenario fio will not
+ verify the block number written in the header. The header seed won't be
+ verified, unless its explicitly requested by setting
+ :option:`verify_header_seed`. Note in this scenario the header seed check
+ will only work if the read invocation exactly matches the original write
+ invocation.
+
+ If the data direction includes any form of write, the verify will be of the
+ newly written data.
To avoid false verification errors, do not use the norandommap option when
verifying data with async I/O engines and I/O depths > 1. Or use the
diff --git a/backend.c b/backend.c
index f3e5b56a..f5cfffdb 100644
--- a/backend.c
+++ b/backend.c
@@ -1069,6 +1069,17 @@ static void do_io(struct thread_data *td, uint64_t *bytes_done)
if (td->o.verify != VERIFY_NONE && io_u->ddir == DDIR_READ &&
((io_u->flags & IO_U_F_VER_LIST) || !td_rw(td))) {
+ /*
+ * For read only workloads generate the seed. This way
+ * we can still verify header seed at any later
+ * invocation.
+ */
+ if (!td_write(td) && !td->o.verify_pattern_bytes) {
+ io_u->rand_seed = __rand(&td->verify_state);
+ if (sizeof(int) != sizeof(long *))
+ io_u->rand_seed *= __rand(&td->verify_state);
+ }
+
if (verify_state_should_stop(td, io_u)) {
put_io_u(td, io_u);
break;
diff --git a/fio.1 b/fio.1
index 1342a23a..3fbc1657 100644
--- a/fio.1
+++ b/fio.1
@@ -3634,10 +3634,17 @@ Only pretend to verify. Useful for testing internals with
.RE
.P
This option can be used for repeated burn\-in tests of a system to make sure
-that the written data is also correctly read back. If the data direction
-given is a read or random read, fio will assume that it should verify a
-previously written file. If the data direction includes any form of write,
-the verify will be of the newly written data.
+that the written data is also correctly read back.
+.P
+If the data direction given is a read or random read, fio will assume that it
+should verify a previously written file. In this scenario fio will not verify
+the block number written in the header. The header seed won't be verified,
+unless its explicitly requested by setting \fBverify_header_seed\fR option.
+Note in this scenario the header seed check will only work if the read
+invocation exactly matches the original write invocation.
+.P
+If the data direction includes any form of write, the verify will be of the
+newly written data.
.P
To avoid false verification errors, do not use the norandommap option when
verifying data with async I/O engines and I/O depths > 1. Or use the
--
2.25.1
