Skip to content
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

Option in fio to log with the same epoch as CLOCK_MONOTONIC_RAW #1314

Closed
aggieNick02 opened this issue Dec 13, 2021 · 4 comments
Closed

Option in fio to log with the same epoch as CLOCK_MONOTONIC_RAW #1314

aggieNick02 opened this issue Dec 13, 2021 · 4 comments

Comments

@aggieNick02
Copy link
Contributor

Right now fio offers two options for the various bandwidth, latency, etc. log files. You can use an epoch that is very close to when fio starts running, or the unix epoch.

If you are trying to synchronize your fio logs with other data acquired from other processes during a fio run, neither of these is a great option. (A good example would be another process running to acquire temperature data from the disk being tested.)

The default epoch - when fio starts running - is private to fio. Other processes don't know what it is, and the logs all start with times close to 0. The unix epoch is obtained via gettimeofday(), and is subject to discontinuity and not guaranteed to be monotonic (e.g.,ntp adjustments)

For logs from two processes to be synchronized, they need to be able to speak in terms of a common epoch in a continuous and monotonic time system.

I'm pretty sure all that is needed to support synchronizing fio logs with other processes is to allow for a different epoch to be used - namely, whatever epoch is used by CLOCK_MONOTONIC_RAW (clock_gettime(CLOCK_MONOTONIC_RAW,ts);) .

Would fio be open to this option? If so, I'd be happy to work on the PR. I'd expect it to only be a few lines of code.

@axboe
Copy link
Owner

axboe commented Dec 13, 2021

That sounds useful, please do feel free to work on that change.

@aggieNick02
Copy link
Contributor Author

Thanks for the quick feedback. I'll try to get a PR fairly quickly - first time to build it so I'll be learning a bit.

aggieNick02 added a commit to PCPartPicker/fio that referenced this issue Dec 15, 2021
Add options log_alternate_epoch and log_alternate_epoch_clock_id. This
is similar to the log_unix_epoch option. This resolves the issue raised
in Issue axboe#1314

log_alternate_epoch, if true, causes log files to use the same epoch
used used by the clock_id parameter to the unix clock_gettime function,
where clock_id is specified by the log_alternate_epoch_clock_id option.

This is particularly useful as it allows us to specify a clock id like
CLOCK_MONOTONIC_RAW, which is natural for synchronizing log files
between processes. The current log_unix_epoch is problematic for that
purpose because that clock is not monotonic or continuous.

It turns out that log_unix_epoch is actually equivalent to
log_alternate_epoch with log_alternate_epoch_clock_id set to
CLOCK_REALTIME=0. Since this is the default value of the
log_alternate_epoch_clock_id option anyways, we treat
log_alternate_epoch and log_unix_epoch as equivalent in functionality,
retaining the latter to avoid breaking existing clients.

Signed-off-by: Nick Neumann <nick@pcpartpicker.com>
@aggieNick02
Copy link
Contributor Author

@axboe I have a PR at #1315 for this little feature. I'm not sure if y'all take PRs directly here or need it in a different format. Just let me know if you have any feedback, questions, or changes you'd like. Thanks!

@aggieNick02
Copy link
Contributor Author

This was fixed by #1315

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants