Add AIO and Direct IO support for IOR phases by jxiong · Pull Request #104 · IO500/io500

jxiong · 2026-03-01T00:47:49Z

This commit introduces a set of features and fixes to improve IOR execution flexibility and overall test stability:

IOR Execution Enhancements:

Added '--with-aio' to IOR configuration in prepare.sh to enable AIO.
Introduced 'direct' option for IOR phases to support '--posix.odirect'.
Added 'iteration' option to the IOR easy read phase.

Phase Execution & Validation:

Added should_run_phase() check in main.c to properly skip disabled phases.
Improved the stonewall condition validation logic in phase_dbg.c.

Bug Fixes:

Added CFLAGS="-fPIC" for pfind compilation in prepare.sh.
Fixed missing return value validation for fread() in phase_mdworkbench.c.

This commit introduces a set of features and fixes to improve IOR execution flexibility and overall test stability: IOR Execution Enhancements: - Added '--with-aio' to IOR configuration in prepare.sh to enable AIO. - Introduced 'direct' option for IOR phases to support '--posix.odirect'. - Added 'iteration' option to the IOR easy read phase. Phase Execution & Validation: - Added should_run_phase() check in main.c to properly skip disabled phases. - Improved the stonewall condition validation logic in phase_dbg.c. Bug Fixes: - Added CFLAGS="-fPIC" for pfind compilation in prepare.sh. - Fixed missing return value validation for fread() in phase_mdworkbench.c. Signed-off-by: Jinshan Xiong <jinshanx@google.com>

seattleplus · 2026-03-05T18:03:52Z

Huge thanks for the patch.

I think the "IOR execution" portions of direct, iteration, aio need further discussion and should be separated into a separate PR. The bug fixes and phase execution would also be great if they could be separated into 2 separate PRs.

On the ior execution pieces, the iteration part is not in the spirit of io500 and could bias the results, and so that will not be accepted. We need to discuss the aio portion, as we might prefer for users to just do this another way...but thank you for the example of how to get it done. On the direct, we don't want to add a new var to the function for every new option, so we might think about ways to generalize this, but thanks for the patch as an example of how to get started.

I'm a bit confused as to why should_run_phase is needed?

I'll let the others comment on the other fixes...

jxiong · 2026-03-05T18:30:55Z

For the direct part, I can make it to 'aio --posix.direct' just like the current 'POSIX --posix.direct' does.

iteration is to stabilize the reading result. The publishers will run the whole tests multiple times and pick the best ones anyways, why not make their life easier by embedding this option? I will remove it in the next refresh.

The should_run_phase() is to honor the config options in the ini file. Otherwise it would have this results:

ERROR INVALID (src/main.c:437) Runtime of phase (0.000012) is below stonewall time. This shouldn't happen!
ERROR INVALID (src/main.c:443) Runtime is smaller than expected minimum runtime
[RESULT]    mdtest-hard-write        0.000000 kIOPS : time 0.000 seconds [INVALID]

I agree the fix is not necessary for a valid run but just trying to make it better. In my recent io500 run, I didn't include anything from this patch.

gflofst · 2026-03-11T16:16:46Z

@JulianKunkel, can you comment on some of the deeper code changes? We aren't sure about the implications of this.

JulianKunkel · 2026-03-14T16:36:12Z

For me, this appears to works for individual phases:
API = AIO --aio.max-pending=128 --aio.granularity=8 --posix.odirect

(using the latest IOR main)

JulianKunkel

See my comments please.

JulianKunkel · 2026-03-04T17:00:01Z

src/phase_mdworkbench.c

I agree to this change.

JulianKunkel · 2026-03-04T17:01:30Z

prepare.sh

Wouldn't accept these changes, anyone can modify it. We will integrate some change to clarify that you are allowed to change it.

JulianKunkel · 2026-03-04T17:05:39Z

src/phase_ior_easy.c

  {"uniqueDir", "Use unique directory per file per process", 0, INI_BOOL, "FALSE", & ior_easy_o.uniqueDir},
  {"run", "Run this phase", 0, INI_BOOL, "TRUE", & ior_easy_o.run},
  {"verbosity", "The verbosity level", 0, INI_INT, 0, & ior_easy_o.verbosity},
+  {"direct", "Use direct IO (posix.odirect)", 0, INI_BOOL, "TRUE", & ior_easy_o.direct},


Can make an exception for supporting posix.odirect for AIO module.
I suppose you tried using --posix.odirect even though AIO is used?
Let's recap what users expect.

I think what should have worked was sth like:
API = POSIX --aio.max-pending=128 --aio.granularity=8 --posix.odirect
Or did it not?

This is using POSIX direct IO. What I am trying to do is to enable AIO + direct IO. Something like AIO --aio.max-pending=128 --aio.granularity=8 --posix.odirect would be equivalent but I didn't test it out.

EDITTED: AIO --aio.max-pending=128 --aio.granularity=8 --posix.odirect works with a warning message to complain prefix with --with-aio in the IOR build config.

IO500 version 66fac1a7cca8 (standard) ; WARNING Provided API option --posix.odirect starts with a different prefix and might be not supported - don't worry if you checked! WARNING Provided API option --posix.odirect starts with a different prefix and might be not supported - don't worry if you checked! WARNING Provided API option --posix.odirect starts with a different prefix and might be not supported - don't worry if you checked!

JulianKunkel · 2026-03-04T17:06:17Z

src/main.c

Remind me, why is the current approach not sufficient? It does check right?

yeah I think I can deprecate this patch.

adilger · 2026-03-16T19:05:53Z

Hi @jxiong, can you please split your PR into separate patches for each of the parts, so that they can be reviewed and landed separately.

jxiong · 2026-03-17T04:15:56Z

Hi @jxiong, can you please split your PR into separate patches for each of the parts, so that they can be reviewed and landed separately.

Will do

jxiong requested a review from a team as a code owner March 1, 2026 00:47

jxiong marked this pull request as draft March 5, 2026 04:51

seattleplus assigned adilger and JulianKunkel Mar 11, 2026

JulianKunkel requested changes Mar 14, 2026

View reviewed changes

JulianKunkel pushed a commit that referenced this pull request Mar 18, 2026

Cherry pickign warning from #104. Thanks @jxiong

74f3e76

Conversation

jxiong commented Mar 1, 2026

Uh oh!

seattleplus commented Mar 5, 2026

Uh oh!

jxiong commented Mar 5, 2026

Uh oh!

gflofst commented Mar 11, 2026

Uh oh!

JulianKunkel commented Mar 14, 2026

Uh oh!

JulianKunkel left a comment

Choose a reason for hiding this comment

Uh oh!

JulianKunkel Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

JulianKunkel Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

JulianKunkel Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

jxiong Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JulianKunkel Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

jxiong Mar 17, 2026

Choose a reason for hiding this comment

Uh oh!

adilger commented Mar 16, 2026

Uh oh!

jxiong commented Mar 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jxiong Mar 17, 2026 •

edited

Loading