verify: header seed check for read only workloads

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@samsung.com>

diff --git a/HOWTO.rst b/HOWTO.rst
index a0174318be25b098b715ea9febf52b73732a20b5..04317b1c28ef224aa0905349712aad1230017ee5 100644 (file)
--- a/HOWTO.rst
+++ b/HOWTO.rst
@@ -3909,10 +3909,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 f3e5b56a4a470966acdb7b005969aaaf0205d317..f5cfffdb947f7b71d31317939196d2a1099f18fc 100644 (file)
--- 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 2f45390481433d76f1eb0d8f47b4fa317bafdf73..bb8fb60d8f735efb35db3e0d3530663c0cf4628e 100644 (file)
--- a/fio.1
+++ b/fio.1
@@ -3636,10 +3636,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