Reports write I/Os in job stats and logs for -verify_only even though no writes were issued

[horshack-dpreview]

Please acknowledge the following before creating a ticket

• I have read the GitHub issues section of REPORTING-BUGS.

Description of the bug:
The -verify_only flags allows a verify-only operation even if a write workload is specified. This is expected and described in the manual: "Do not perform specified workload, only verify data still matches previous invocation of this workload." However, after completing a -verify_only run, fio reports that it issued writes for the test, the number of which match the number of writes that would've been issued had fio actually wrote the data (it didn't).

Environment:
Ubuntu 22.04.1 LTS

fio version:
3.33-68

Reproduction steps
fio -bs=64K -rw=write -size=10M -filename=/tmp/test.bin -name="test" -verify=xxhash
then
fio -bs=64K -rw=write -size=10M -filename=/tmp/test.bin -name="test" -verify=xxhash -verify_only

Verify-only reports:
issued rwts: total=160,160,0,0 short=0,0,0,0 dropped=0,0,0,0

If I enable a log such as bandwidth then it too reports data points implying writes were issued even though they weren't. Here is a sample bandwidth log, run on an actual device and with -size=1GB so that the test runs long enough to yield log samples:

610, 1718977, 1, 0, 0
1250, 0, 1, 0, 0
1999, 0, 1, 0, 0
2612, 0, 1, 0, 0

[vincentkfu]

This seems like mainly a reporting issue. With --verify_only=1 fio goes through the motions of issuing write operations in order to set everything up for verification.

In backend.c we have:

		if (td->o.verify_only && td_write(td))
			verify_bytes = do_dry_run(td);
		else {
			do_io(td, bytes_done);

			if (!ddir_rw_sum(bytes_done)) {
				fio_mark_td_terminate(td);
				verify_bytes = 0;
			} else {
				verify_bytes = bytes_done[DDIR_WRITE] +
						bytes_done[DDIR_TRIM];
			}
		}

do_dry_run() is:

/*
 * Dry run to compute correct state of numberio for verification.
 */
static uint64_t do_dry_run(struct thread_data *td)
{
	td_set_runstate(td, TD_RUNNING);

	while ((td->o.read_iolog_file && !flist_empty(&td->io_log_list)) ||
		(!flist_empty(&td->trim_list)) || !io_complete_bytes_exceeded(td)) {
		struct io_u *io_u;
		int ret;

		if (td->terminate || td->done)
			break;

		io_u = get_io_u(td);
		if (IS_ERR_OR_NULL(io_u))
			break;

		io_u_set(td, io_u, IO_U_F_FLIGHT);
		io_u->error = 0;
		io_u->resid = 0;
		if (ddir_rw(acct_ddir(io_u)))
			td->io_issues[acct_ddir(io_u)]++;
		if (ddir_rw(io_u->ddir)) {
			io_u_mark_depth(td, 1);
			td->ts.total_io_u[io_u->ddir]++;
		}

		if (td_write(td) && io_u->ddir == DDIR_WRITE &&
		    td->o.do_verify &&
		    td->o.verify != VERIFY_NONE &&
		    !td->o.experimental_verify)
			log_io_piece(td, io_u);

		ret = io_u_sync_complete(td, io_u);
		(void) ret;
	}

	return td->bytes_done[DDIR_WRITE] + td->bytes_done[DDIR_TRIM];
}

Fio generates all the write IOs but never actually submits them. This will be tricky but it seems like the appropriate thing to do is to suppress all the undesirable logging that happens in this phase. We would have to make sure that anything we suppress is not needed for verification.

[horshack-dpreview]

Thanks for looking into it. This is a very low severity issue so if it's anything but trivial to fix I'd be happy to mark it closed if that's your preference.

[vincentkfu]

I don't have a problem with leaving this open. This is something that would be nice to clean up and having this will be a reminder.