Multi-job based data verification #2025
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Background FIO has supported data verification integrity test based on per-job methodology. Each job should have its own dedicated offset area to make sure that other jobs do not corrupt the written offsets to keep the consistency based on the job point-of-view. NVMe spec supports various I/O commands causing written data pattern(e.g., zeroes) or status(e.g., unmap, uncor) updated. This means that these commands should be the candidates necessarily used for the data verification test. It leads to a demand for multiple jobs issuing various write-family commands to the same area and see the *latest* snapshot of written data pattern or status. This patch added a new option `--verify_table_id=<n>` to represent the verification table identifier for multiple jobs. If one or more jobs have the same value for this option, they will share the verification table, which is a lock-free concurrent skiplist to keep the `ipo`, i.e., io pieces. This patch does not change any functionalities for the previous dedicated area-based data verification if `--verify_table_id=` option is not given. The classical data verify methodology will keep as flist or rb-tree. This shared verify table also considers trimmed offset by setting `ipo->flags` with IP_F_TRIMMED and when the read phase starts, it will be treated as it was. Basically, fio verify job starts on the its own job context (thread or process) each. But, when the jobs are sharing the same verify table id, one of the jobs will win the race and only a single job will do the verify phase by atomic operation. Currently this patch only supports thread-based usages (--thread=1) for the simplicity. Signed-off-by: Minwoo Im <[email protected]>
As TRIM does, some I/O requests can cause written data pattern(e.g., zeroed) or status updated(uncor). This patch, for example, added support for IO_U_F_TRIMMED, IO_U_F_ZEROED, and IO_U_F_ERRORED for NVMe commands to io_uring ioengine. Signed-off-by: Minwoo Im <[email protected]>
For example, in io_uring_cmd with nvme cmd_type, trimmed offset might return NVMe status code to represent the given offsets are unmapped. In this case, failure might be expected. This patch added a new option just like the other trim_verify_* series to maskd the expected error value from the ioengine. Signed-off-by: Minwoo Im <[email protected]>
minwooim
force-pushed
the
shared-verify-table-rebased
branch
from
a3aa301 to
b02ee38
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See the first commit description for the background and details.
The following jobfile is an example for the multiple write job based data verification.
16 jobs are going to write[zeroes, uncor, trim] to the same area [0, 1M).