-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Flush enhancements and fixes #1777
Conversation
0331123
to
8dfaf60
Compare
engines/io_uring.c
Outdated
@@ -39,6 +39,7 @@ enum uring_cmd_write_mode { | |||
FIO_URING_CMD_WMODE_UNCOR, | |||
FIO_URING_CMD_WMODE_ZEROES, | |||
FIO_URING_CMD_WMODE_VERIFY, | |||
FIO_URING_CMD_WMODE_FLUSH, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this added?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uhh... my bad. It's something remaining from the previous approach. Will remove it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still needs to be removed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will remove it!
For the second patch, it looks like what's happening is that fio issues a write, followed by a sync, then a read, then (since For the second patch, why don't you also remove In Also please rename Can you create a test case for this? |
If
then
If you meant
Okay.
Alright, I'll work on the mixed workload and create test cases using the issued rwts section of the report. |
8dfaf60
to
ac1fa5f
Compare
I've added a test case to test whether FLUSH commands are issued properly or not. |
fio.h
Outdated
@@ -629,7 +630,7 @@ static inline bool multi_range_trim(struct thread_data *td, struct io_u *io_u) | |||
|
|||
static inline bool should_fsync(struct thread_data *td) | |||
{ | |||
if (td->last_was_sync) | |||
if (td->last_ddir_issued == DDIR_SYNC) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With last_was_sync
we had:
td->last_was_sync = ddir_sync(io_u->ddir);
So this should use ddir_sync()
instead of checking for equality with DDIR_SYNC
because we actually have three different sync DDIRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed! will fix it. Thanks.
For the Finally, the test cases look good but can you just add them to |
Sure, I will.
Okay. |
Don't forget to remove the superfluous item from |
Add support for --fsync and --fdatasync in io_uring_cmd ioengine to enable FLUSH commands just like libaio or io_uring ioengines. If --fsync or --fdatasync is given N, FLUSH command will be issued as per N write commands. Signed-off-by: Minwoo Im <minwoo.im.dev@gmail.com>
`last_ddir` represents the data direction of the latest completed command. To avoid confusions, this patch renamed `last_ddir` to `last_ddir_completed` to make it much more clear. Signed-off-by: Minwoo Im <minwoo.im.dev@gmail.com>
ac1fa5f
to
9d3f7dd
Compare
Applied review comments, Thanks for your time. |
ioengines.c
Outdated
@@ -466,6 +462,7 @@ enum fio_q_status td_io_queue(struct thread_data *td, struct io_u *io_u) | |||
} | |||
} | |||
|
|||
td->last_ddir_issued = ddir; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not notice this in the previous version of your patch but if ret == FIO_Q_BUSY
then the I/O was not actually issued. Assignment of last_ddir_issued
should go in the two places where last_was_sync
was set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, indeed. Let me fix this up!
@@ -101,7 +101,6 @@ static void reset_io_counters(struct thread_data *td, int all) | |||
|
|||
td->zone_bytes = 0; | |||
|
|||
td->last_was_sync = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we never should have set last_was_sync
to false here because when ramp time is over we want to continue to sync at the appropriate point, so there is no need to modify the value for last_ddir_issued
. Agree?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you meant we don't need to modify the value of last_ddir_issued
in this place, yes, I agree.
`last_was_sync` has represented that the last command had DDIR_SYNC. This can be replaced with `ddir_sync(last_ddir_issued)` and it's much more flexible to represent the last issued command's data direction. Signed-off-by: Minwoo Im <minwoo.im.dev@gmail.com>
When using `--rw=write --fsync=N`, the FLUSH command is correctly issued after N WRITE commands. However, if READ commands are mixed in with --rw, fsync occurs after READ commands as well. This patch ensures that fsync is only triggered after the specified number of WRITE commands, regardless of READ commands. Signed-off-by: Minwoo Im <minwoo.im.dev@gmail.com>
Even if ddir is determined in get_rw_ddir(), ddir might be updated in set_rw_ddir(). if td represents trimwrite, it will be updated to either DDIR_TRIM or DDIR_WRITE even ddir already represents for DDIR_SYNC. To support DDIR_SYNC(fsync) for trimwrite, this patch checks ddir_sync() in case of trimwrite not to update the pre-determined ddir. Signed-off-by: Minwoo Im <minwoo.im.dev@gmail.com>
This test script tests number of FLUSH commands triggered by --fsync=<N> options to make FLUSH commands are followed by the WRITE commands from the various --rw I/O workload. Signed-off-by: Minwoo Im <minwoo.im.dev@gmail.com>
9d3f7dd
to
e84adcf
Compare
Applied, thanks. |
This patchset introduces enhancements of fsync/fdatasync operations and
fixes. The first patch added support for NVMe FLUSH commands in
io_uring_cmd ioengine. The second one fixes issuing fsync/fdatasync
even if the previous command is READ. As documentation says, fsync
should sync the file after every N WRITE commands issued. The third one
fixes not issuing fsync/fdatasync in trimwrite worklload.
report.
Minwoo Im (4):
io_uring: Add support FLUSH command
io_u: ensure fsync only after write(s)
io_u: Support fsync for --rw=trimwrite