fio: remove raw device support

As of Linux kernel commit 603e4922f1c ("remove the raw driver"),
linux/raw.h is gone, and raw device support no longer exists.
Because of this, fio can no longer build against the current Linux
kernel headers.

So, remove raw device support from fio as well.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

iolog: don't attempt read chunking with blktrace format

Signed-off-by: Jens Axboe <axboe@kernel.dk>

Merge branch 'master' of https://github.com/anson-lo/fio

* 'master' of https://github.com/anson-lo/fio:
  Fix an error triggered by double releasing the lock

Fix an error triggered by double releasing the lock

Fix an error triggered by double releasing the lock.
Fixes: https://github.com/axboe/fio/issues/1254.

Signed-off-by: Anson Lo ycaibb@gmail.com

Makefile: update libzbc git repository

Update the GIT repository used for libzbc in the fulltes directive from
pointing to the now deprecated hgst reporitory to the currentxi
https://github.com/westerndigitalcorporation/libzbc repository.

Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Merge branch 'evelu-fix-engines' of https://github.com/ErwanAliasr1/fio

* 'evelu-fix-engines' of https://github.com/ErwanAliasr1/fio:
  engines/exec: Code cleanup to remove leaks

engines/exec: Code cleanup to remove leaks

As per the coverty reports, there was some issues in my code :
- Some structures were not properly freed before returning.
- Some file descriptors were not properly closed
- Testing with 'if (!int)' isn't a good way to test if the value is negative

Signed-off-by: Erwan Velu <erwanaliasr1@gmail.com>

engines/exec: style cleanups

No functional changes in this patch.

Signed-off-by: Jens Axboe <axboe@kernel.dk>

Merge branch 'evelu-exec' of https://github.com/ErwanAliasr1/fio

* 'evelu-exec' of https://github.com/ErwanAliasr1/fio:
  fiograph: Adding exec engine support
  engines: Adding exec engine

Merge branch 'dedupe_workset' of https://github.com/bardavid/fio

* 'dedupe_workset' of https://github.com/bardavid/fio:
  dedupe: allow to generate dedupe buffers from working set

Merge branch 'cmd-test-be' of https://github.com/tuan-hoang1/fio

* 'cmd-test-be' of https://github.com/tuan-hoang1/fio:
  server: fix missing le32_to_cpu conversion when opcode is FIO_NET_CMD_TEXT

server: fix missing le32_to_cpu conversion when opcode is FIO_NET_CMD_TEXT

Reported-by: Manuel Gotin <manuel.gotin@ibm.com>
Signed-off-by: Tuan Hoang <tmhoang@linux.ibm.com>

dedupe: allow to generate dedupe buffers from working set

This commit introduced new dedupe generation mode "working_set".
Working set mode simulates a more realistic approach to deduped data,
in which deduped buffers are generated from pre-existing working set -
% size of the device or file.

In other words, dedupe is not usually expected to be close
in time with the source buffer, as well as source buffers
are usually composed of small subset of the entire file or device.

Signed-off-by: Bar David <bardavvid@gmail.com>

Makefile: use override directive on engine CFLAGS

The GNU Make documentation says the following about the override
keyword:

  Subsequent assignments or appends to this variable which are not
  marked override will be ignored.

  https://www.gnu.org/software/make/manual/html_node/Override-Directive.html

When the override CFLAGS line was moved in commit
f4bd2c3d80bc35f76892205a7e50426711e3def3 it broke the engine template,
which does not use the override directive. Since the engine template is
now evaluated afterwards, the engine CFLAGS are ignored.

Add the override keyword to the engine template so that engine CFLAGS
are honored again.

Note that the CONFIG_DYNAMIC_ENGINES case doesn't need the override
directive. It seems that GNU Make assigns CFLAGS even without the
override directive in this case:

  $$($(1)_OBJS): CFLAGS := -fPIC $$($(1)_CFLAGS) $(CFLAGS)

Fixes: f4bd2c3d80bc35f76892205a7e50426711e3def3 ("fix dynamic engine build")
Cc: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Merge branch 'dedupe_bugfix' of https://github.com/bardavid/fio

* 'dedupe_bugfix' of https://github.com/bardavid/fio:
  dedupe: fixing bug with subsequent dedupe buffer generation

dedupe: fixing bug with subsequent dedupe buffer generation

When unique pages are generated onto the write buffer the seed
used to generate the page is copied later to the buf_state_prev
for future dedupe generation.

However, the get_buf_state API returns pointer to the prev
seed. Then when the caller uses it to re-generate the buffer
it changes the internal seed and advances the PRNG.
A subsequent intention to create another dedup might result in
generating a unique page instead.

Signed-off-by: Bar David <bardavvid@gmail.com>

fiograph: Adding exec engine support

Since fiograph is merged, let's add the specific options of this engine
into it and render the example job.

Signed-off-by: Erwan Velu <e.velu@criteo.com>

engines: Adding exec engine

When performing benchmarks with fio, some need to execute
tasks in parallel to the job execution. A typical use-case would be
observing performance/power metrics.

Several implementations were possible :
 - Adding an exec_run in addition of the existing exec_{pre|post}run
 - Implementating performance/power metrics in fio
 - Adding an exec engine

1°) Adding an exec_run
This was my first intention but quickly noticed that exec_{pre-post}run
are executed for each 'numjob'. In the case of performance/power
monitoring, this doesn't make sense to spawn an instance for each
thread.

2°) Implementing performance/power metrics
This is possible but would require lot of work to maintain this part of
fio while 3rd party tools already take care of that perfectly.

3°) Adding an engine
Adding an engine let users defining when and how many instances of the program they want.
In the provided example, a single monitoring job is spawning at the same
time as the worker thread which could be composed of several worker
threads.
A stonewall barrier is used to define which jobs must run together
(monitoring / benchmark).

The engine has two parameters :
- program: name of the program to run
- arguments: arguments to pass to the program
- grace_time: duration between SIGTERM and SIGKILL
- std_redirect: redirect std{err|out} to dedicated files

Arguments can have special variables to be expanded before the execution:
- %r will be replaced by the job duration in seconds
- %n will be replaced by the job name

During the program execution, the std{out|err} are redirected to files if std_redirect option is set (default).
- stdout: <job_name>.stdout
- stderr: <job_name>.stderr

If the executed program has a nice stdout output, after the fio
execution, the stdout file can be parsed by other tools like CI jobs or graphing tools.

A sample job is provided here to show how this can be used.
It runs twice the CPU engine with two different CPU modes (noop vs qsort).
For each benchmark, the output of turbostat is saved for later analysis.
After the fio run, it is possible to compare the impact of the two modes
on the CPU frequency and power consumption.

This can be easily extended to any other usage that needs to analysis
the behavior of the host during some jobs.

About the implementation, the exec engine forks :
- the child doing an execvp() of the program.
- the parent, fio, will monitor the time passed into the job

Once the time is over, the program is SIGTERM followed by a SIGKILL to
ensure it will not run _after_ the job is completed.
This mechanism is required as :
- not all programs can be controlled properly
- that's last resort protection if the program gets crazy
The delay is controlled by grace_time option, default is 1 sec.

If the program can be limited in its duration, using the %r variable in
the arguments can be used to request the program to stop _before_ the
job finished like :
        program=/usr/bin/mytool.sh
        arguments=--duration %r

Signed-off-by: Erwan Velu <e.velu@criteo.com>

zbd: ensure that global max open zones limit is respected

Commit 219c662d3b12 ("zbd: introduce per job maximum open zones limit")
Introduced a global max open zones limit stored in zbd_info->max_open_zones.

This commit also changed checks against td->o.max_open_zones in zbd_open_zone()
with checks against zbd_info->max_open_zones.

It is obvious that zbd_info->max_open_zones was intended to replace
td->o.max_open_zones in all code that is executed after zbd_setup_files().

The commit itself was needed since zbd_info is shared over different jobs,
so it is important that the global limit of max open zones is the same,
for different jobs targeting the same device.

The problem with this commit is that in zbd_convert_to_open_zone(),
instead of replacing td->o.max_open_zones with zbd_info->max_open_zones,
it incorrectly just removed the references to td->o.max_open_zones.

This caused commit 00ca8df5468e ("zbd: Fix max_open_zones checks")
(written by another author) to incorrectly re-add the removed
td->o.max_open_zones checks in zbd_convert_to_open_zone().
The proper fix here should have been to add checks against
zbd_info->max_open_zones instead of td->o.max_open_zones,
just like the original author did for zbd_open_zone().

Replace all td->o.max_open_zones uses past zbd_setup_files() with
zbd_info->max_open_zones, and force set td->o.max_open_zones to
zbd_info->max_open_zones in zbd_setup_files(), so that even if checks are
introduced against the wrong limit, fio will still respect the global limit.

Fixes: 00ca8df5468e ("zbd: Fix max_open_zones checks")
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

zbd: allow an unlimited global max open zones limit

Commit 219c662d3b12 ("zbd: introduce per job maximum open zones limit")
Introduced a global max open zones limit stored in zbd_info->max_open_zones.

This commit also removed the following check from zbd_open_zone():

if (!td->o.max_open_zones)
        return true;

Before the commit in question, if td->o.max_open_zones == 0, zbd_open_zone()
would not track the zone as open in the zbd_info->open_zones array.

After the commit in question, zbd_open_zone() would always track the zone
as open in the zbd_info->open_zones array, regardless if a --max_open_zones
limit was set or not.

Change the initialization of zbd_info->max_open_zones to yet again allow
unlimited max open zones. If zbd_info->max_open_zones is unlimited,
we do not track the open zones in the zbd_info->open zone array.

Not tracking open zones reduces fio overhead for testing the performance of
zoned block devices that do not have a limit on the maximum number of open
zones.

Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

zbd: create a local zbdi variable for f->zbd_info

Create a local zbdi variable for f->zbd_info for the following functions:
zbd_open_zone(), zbd_convert_to_open_zone(), and zbd_adjust_block().

This avoids unnecessary indirections.

No functional change intended.

Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Merge branch 'evelu-fiog' of https://github.com/ErwanAliasr1/fio

* 'evelu-fiog' of https://github.com/ErwanAliasr1/fio:
  examples: Avoid duplicated items
  tools: Adding fiograph

examples: Avoid duplicated items

Some jobs were defining variable twice,
some jobs were defined twice.

This commit ensure that examples are items are named only once.

Signed-off-by: Erwan Velu <erwanaliasr1@gmail.com>

tools: Adding fiograph

This tool generates graphviz graphs of any fio job file.

Reading a fio file can be sometimes tricky when :
  - you have lots of jobs
  - jobs override some options
  - jobs have dependencies

Understanding which jobs are running at the same time, which one waits
for which is sometimes difficult and could easily lead to mistakes.
It's pretty common to find jobs where people think jobs are sequential
while some run in parallel.

For ease the understanding of the scheduling and what's the
configuration status (local + global variables), this tool will use some
graphical helpers to enlighten things.

The configuration file can be used to adjust the rendering but by default :
  - jobs are defined in a blue rounded box
  - jobs running at the same time are inside the same gray background
  - time & size variables are shown as a self arrow
  - dependencies between jobs are shown by up->down black arrows
  - specific engines options are written in blue (top of the job box)
  - standard options are printed in green (bottom of the job box)
  - pre/post actions are printed in red (head/tail of the job box)
  - numjobs is replaced by a 'x' multiplicator on the job name

Several output formats can be defined via --format : list can be found
here https://graphviz.org/docs/outputs/

if --view option is used, the rendered file will be immediately shown.

if --keep is used, the grapvhiz file will be kept.

This commit also adds the rendering of the examples jobs.
If a newcomer gets into the repository, they can immediately better
understand what the jobs do.

Signed-off-by: Erwan Velu <erwanaliasr1@gmail.com>

Merge branch 'pkg_config_1' of https://github.com/kusumi/fio

* 'pkg_config_1' of https://github.com/kusumi/fio:
  configure: silence "pkg-config: not found"

filehash: ignore hashed file with fd == -1

This can happen sporadically during setup, and it need not be a
failure condition.

Signed-off-by: Jens Axboe <axboe@kernel.dk>

t/zbd: update test case 42

Update test case 42 to grep for the new string printed by fio when
--zonesize=0 is supplied.

Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

zbd: change some f->zbd_info conditionals to asserts

Unfortunately, generic fio code calls some zbd_* functions unconditionally.
These functions will be called regardless if zonemode == ZONE_MODE_NONE,
ZONE_MODE_STRIDED or ZONE_MODE_ZBD, and cannot be optimized.

However, some functions are only called when zonemode == ZONE_MODE_ZBD.
Since f->zbd_info will always be non-NULL for a job with zonemode=zbd,
these functions can be optimized to not check if f->zbd_info is set.

Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

zbd: remove zbd_zoned_model ZBD_IGNORE

For a job with zonemode=zbd, we do not want any file to be ignored.
Each file's file type in that job should be supported by either zbd.c
or the ioengine. If not, we should return an error.
This way, ZBD_IGNORE becomes redundant and can be removed.

By removing ZBD_IGNORE, we know that all files belonging to a job that
has zonemode=zbd set, will either be a zoned block device, or emulate
a zoned block device.

This means that for jobs that have zonemode=zbd, f->zbd_info will always
be non-NULL. This will make the zbd code slightly easier to reason about
and to maintain.

When removing zbd_zoned_model ZBD_IGNORE, define the new first enum value
as 0x1, so that we avoid potential ABI problems with existing binaries.

Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

zbd: allow zonemode=zbd with regular files by emulating zones

Currently when using zonemode=zbd and running against a regular file,
fio will fail with:
fio: file hash not empty on exit

Treat regular files just like how we treat regular (non-zoned) block
devices: return ZBD_NONE and let zbd.c emulate zones inside the regular
file/block device.

Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

zbd: disallow pipes for zonemode=zbd

zoned block device support in fio cannot handle pipes,
so simply reject them and give a clear error message.

Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

io_uring: drop redundant IO_MODE_OFFLOAD check

check_engine_ops() already returns an error if io_submit_mode is
IO_MODE_OFFLOAD and the engine is marked FIO_NO_OFFLOAD.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

t/zbd: Fix write target zones counting in test case #31

The test case #31 in t/zbd/test-zbd-support writes 128KB data to
sequential write required zones as the preparation for the following
random read test. The data write leaves the target zones in open status.
The test case refers the variable 'nz', which has max_open_zones value,
to decide how many zones to write the data. However, the end condition
of the write target zone loop has a bug. The disk end offset is used as
the loop end condition, which does not match the last target zone when
number of sequential write required zones divided by nz has remainder.
This results in write to more zones than nz=max_open_zones limit and the
test case failure. To fix the bug and to simplify the script, avoid the
loop and utilize zonemode strided to achieve the same data write
pattern. Also specify size and io_size using nz to reliably count the
write target zones.

Even with the fix above, still the number of open zones may exceed
max_open_zones since other test cases executed before the test case 31
may leave open zones on the test target device. To avoid this failure,
reset all zones before the data write.

The failures were observed with libzbc I/O engine after the commit
e8267436fd7a ("engines/libzbc: add support for the get_max_open_zones io
op"), which changed the max_open_zones value fio refers.

Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

t/zbd: Add ignore_zone_limit option to test with special max_open_zones

Recent commit d2f442bc0bd5 ("ioengines: add get_max_open_zones zoned
block device operation") modified fio to compare --max_open_zones option
value and max_open_zones reported by the device. When the option
--max_open_zones is larger than the device limit, fio exits with an
error. However, sometimes it is useful to run fio with --max_open_zones
larger than the device limit to check performance impact of implicit
zone open and close by the zoned block devices. The test script
t/zbd/test-zbd-support has an option -o so that users can specify such
larger max_open_zones value. After the commit, such test runs fail with
the fio error.

To avoid the failure, modify the test script to specify another option
--ignore_zone_limits to fio command, which was added by the commit
575686bb85fa (zbd: add a new --ignore_zone_limits option). This option
is added to fio command only when users specify -o option and special
max_open_zones value to the test script. This change does not affect
default test conditions.

Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

t/zbd: Use max_open_zones that fio fetched from device

Recent commit d2f442bc0bd5 ("ioengines: add get_max_open_zones zoned
block device operation") modified fio to compare --max_open_zones option
value and max_open_zones reported by the device. The device limit is
fetched through sysfs or through an ioengine specific implementation.

The test script currently try to fetch the max open zones limit using
libzbc tools or sg_inq. If either of these fail, default value 128 is
supplied. This default value can be too high when the test script is
run for certain zoned block devices, and can therefore result in fio
error and test case failure.

To avoid the failure, modify the default value used in the test script
from 128 to 0. With this, --max_open_zones=0 is passed to fio, and it
makes fio use the max_open_zones reported by the device. Also add
comments to describe why the test script gets max_open_zones with tools.

Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

configure: silence "pkg-config: not found"

Do what check_min_lib_version() does to not print the error message
when pkg-config doesn't exist.

--
DAOS File System (dfs) Engine no
./configure: pkg-config: not found
NFS engine                    no

Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@gmail.com>

Merge branch 'fix/928' of https://github.com/larsks/fio

* 'fix/928' of https://github.com/larsks/fio:
  fix fio2gnuplot to work with new logging format

Merge branch 'evelu-test' of https://github.com/ErwanAliasr1/fio

* 'evelu-test' of https://github.com/ErwanAliasr1/fio:
  Makefile: Avoid using built-in stpcpy during clang build
  ci: Reporting installed msys2 packages
  ci: Installing missing toolchain

Makefile: Avoid using built-in stpcpy during clang build

Since clang 12, during the clang build, noticed by the CI, the linking
fails as clang optimize some string functions to stpcpy.

  LINK fio
lld-link: error: undefined symbol: stpcpy
>>> referenced by C:\projects\fio\options.c:5305
>>>               options.o:(fio_options_parse)

Two possible implementations :
- Adding stpcpy in fio as the kernel did : https://lore.kernel.org/lkml/20200815002417.1512973-1-ndesaulniers@google.com/T/
- Disable the implicit stpcpy

To avoid adding code into fio, the latter option was used.

Signed-off-by: Erwan Velu <e.velu@criteo.com>

ci: Reporting installed msys2 packages

When reproducing a build locally, it's important to be on the same
release as the CI.

So let's listi the installed packages so we can compare the two builds more easily.

Signed-off-by: Erwan Velu <e.velu@criteo.com>

ci: Installing missing toolchain

When trying to rebuild a failed build on a real windows system,
the toolchain is missing.

Let's add the toolchain here so we can reuse the script locally too.

Signed-off-by: Erwan Velu <e.velu@criteo.com>

zbd: add a new --ignore_zone_limits option

In commit d2f442bc0bd5 ("ioengines: add get_max_open_zones zoned block
device operation") we added a check that verifies that the specified
--max_open_zones value is lower than the max value reported by the device.

For ZNS devices there is a max open zones and a max active zones limit.
For ZAC/ZBC devices there is only a max open zones limit.

On ZAC/ZBC, there is thus no limit on the amount of zones that can be
in zone state closed.
When doing a write to an empty or closed zone, a ZAC/ZBC drive will
close an arbitrary implicit open zone in order to handle the write.

The ZNS specification has no requirement on closing a zone in order to
handle a write to an empty or closed zone. The drive is free to return
an error.

Even on ZAC/ZBC, you do not want to exceed the max open zones limit,
since it will lead to additional implicit close zone and implicit open
zone operations, which may degrade performance.
However, it seems that this is sometimes done on purpose, in order to
measure the overhead of these additional operations. Therefore, add
an option that allows the user to ignore the reported device limits.

Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

zbd: add missing client/server support for option max_open_zones

Ensure that we convert the max_open_zones option for client/server.

Use __cpu_to_le32()/__le32_to_cpu() rather than
cpu_to_le32()/le32_to_cpu(), since max_open_zones is defined
as int rather than unsigned int in thread_options.h.

Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Merge branch 'fix-libpmem' of https://github.com/lukaszstolarczuk/fio

* 'fix-libpmem' of https://github.com/lukaszstolarczuk/fio:
  engines/libpmem: do not call drain on close
  engines/libpmem: cleanup a little code, comments and example
  engines/libpmem: set file open/create mode always to RW

Fio 3.27

Signed-off-by: Jens Axboe <axboe@kernel.dk>

Merge branch 'master' of https://github.com/DevriesL/fio

* 'master' of https://github.com/DevriesL/fio:
  android: add support for NDK sharedmem

android: add support for NDK sharedmem

Android add support for NDK sharedmem since API level 26 and prohibit
the directly use of ashmem since API level 29, so we can use sharedmem
if targeting API level is higher than 26.

Signed-off-by: DevriesL <therkduan@gmail.com>

Merge branch 'taras/nfs-upstream' of https://github.com/tarasglek/fio-1

* 'taras/nfs-upstream' of https://github.com/tarasglek/fio-1:
  clean up nfs example
  skip skeleton comments
  single line bodies
  C-style comments
  NFS configure fixes
  NFS engine

Merge branch '2021-05-13/stat-fix-integer-overflow' of https://github.com/flx42/fio

* '2021-05-13/stat-fix-integer-overflow' of https://github.com/flx42/fio:
  stat: fix integer overflow in convert_agg_kbytes_percent

engines/libzbc: add support for the get_max_open_zones io op

Add support for the new .get_max_open_zones io operation.

zbc.c will only ever call this callback for host-managed devices.

Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

ioengines: add get_max_open_zones zoned block device operation

Define a new IO engine operation to get the maximum number of open zones.
Like the existing IO engine operations: .get_zoned_model, .report_zones,
and .reset_wp, this new IO engine operation is only valid for zoned block
devices.

Similarly to the other zbd IO engine operations, also provide a default
implementation inside oslib/linux-blkzoned.c that will be used if the
ioengine does not override it.

The default Linux oslib implementation is implemented similarly to
blkzoned_get_zoned_model(), i.e. it will return a successful error code
even when the sysfs attribute does not exist.
This is because the sysfs max_open_zones attribute was introduced first
in Linux v5.9.
All error handling is still there, so an ioengine that provides its own
implementation will still have its error code respected properly.

Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

oslib/linux-blkzoned: move sysfs reading into its own function

Move the sysfs reading into its own function so that it can be reused.
This new function will be reused in a following patch.

No functional change intended.

Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

zbd: only put an upper limit on max open zones once

There is an upper limit that is checked for each td, and for each file,
even though a file has a pointer to a zoned_block_device_info that has
already been created. Multiple files, from the same or from another td
can point to the same zoned_block_device_info.
All zoned_block_device_info:s have already been created earlier in the
call chain.

Simplify this by only checking the upper limit on max open zones when a
zoned_block_device_info is created.

This way, max_open_zones is handled from a single location, instead of
potentially being reassigned from a completely different location.

Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

stat: fix integer overflow in convert_agg_kbytes_percent

Assuming that "int" is 32-bit, for high bandwidth values (> 21.5 GB/s)
the expression "mean * 100" will cause an integer overflow before the
conversion to "double" happens.

Signed-off-by: Felix Abecassis <fabecassis@nvidia.com>

fix fio2gnuplot to work with new logging format

The logging format updates documented in 1a953d97 were never
propagated to fio2gnuplot, which since then has been failing with a
ValueError exception.

This commit explicits limits fio2gnuplot to only reading the first
4 columns in the log file.

Closes #928

os: define EDQUOT to EIO if the OS doesn't provide it

Fixes: 418f53993b07 ("Make fill_device to stop writing on EDQUOT")
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Make fill_device to stop writing on EDQUOT

Option fill_device stops writing when we run out of quota as well.

Signed-off-by: Martin Bukatovic <martin.bukatovic@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Merge branch 'z_unit_docs' of https://github.com/ahribeng/fio

* 'z_unit_docs' of https://github.com/ahribeng/fio:
  Add Documentation for z unit

oslib/linux-blkzoned: make sure that we always support zone capacity

A common problem is that users upgrade their kernel to support NVMe ZNS
devices, however, they still use the kernel uapi headers provided by their
distro.

This means that even if the kernel will populate the zone capacity fields
for each zone in the zone report returned by the ioctl, fio will not know
how to interpret that data.

This leads to fio writing past the zone capacity, which will lead to
I/O errors.

It is not trivial for a user to realize that the kernel uapi headers
provided by their distro is the reason for these I/O errors.

In order to make it easier for these users, provide a copy of the current
zoned block device kernel uapi structs.

If the kernel uapi headers installed on the system are too old to support
zone capacity, use the locally defined structs instead.
If the installed headers are new enough to support zone capacity, use the
installed headers.

This way, fio will always be able to handle zone capacity (if the kernel
supports it). At the same time, we will not redefine any structs from the
installed headers if they are newer than our locally defined structs.

Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

don't access dlclose'd dynamic ioengine object after close

Alexey reported this bug when using dynamically loaded IO engines;
a segfault on the line where we set the dlhandle to NULL after
the dlclose.

I think this is because ops points to the thing we obtained from dlsym:

ops = dlsym(dlhandle, engine_lib);

and after the final dlclose, the object no longer exists and efforts
to set the handle within it will fail for obvious reasons.
I'm not sure why I hadn't seen this before.

Fixes-RH-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1956963
Reported-by: Alexey Dobriyan <adobriyan@gmail.com>
Fixes: f6931a1 ("fio: move dynamic library handle to io_ops structure")
Tested-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Add Documentation for z unit

configure: fix check_min_lib_version() eval

The following shell statement:

  if eval "echo \$$_feature" = "yes" ; then

executes:

  echo $... = "yes"

It does not actually compare the variable named by $_feature to the
string "yes".

Add the missing "test" call so the comparison happens as intended and
wrap the eval so it doesn't include the = "yes".

Fixes: 3e48f7c9de61 ("configure: fix syntax error with NetBSD")
Cc: Dmitry Fomichev <dmitry.fomichev@wdc.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

clean up nfs example

skip skeleton comments

single line bodies

C-style comments

ioengines: don't call zbd_put_io_u() for engines not implementing commit

Commit d9ed3e63e528 ("zbd: Fix zone locking for async I/O engines") added
a call to zbd_put_io_u() in the case where td->io_ops->commit callback
is not implemented on an ioengine.

The commit in question fails to mention why this zbd_put_io_u() call was
added for ioengines not implementing the commit callback.

The code in td_io_queue() looks like this:

ret = td->io_ops->queue(td, io_u);
zbd_queue_io_u(td, io_u, ret);

if (!td->io_ops->commit) {
io_u_mark_submit(td, 1);
io_u_mark_complete(td, 1);
zbd_put_io_u(td, io_u);
}

SYNC I/O engine case (e.g. psync):
The zone will be locked by zbd_adjust_block(), td->io_ops->queue(td, io_u),
which for a sync I/O engine will return FIO_Q_COMPLETED.

This return value will be send in to zbd_queue_io_u(), which at the end
of the function, unlocks the zone if the return value from ->queue()
differs from FIO_Q_QUEUED. For a sync I/O engine, the zone will be
unlocked here, and io_u->zbd_put_io function pointer will be set to NULL.

psync does not implement the ->commit() callback, so it will call
zbd_put_io_u(), which will do nothing, because the io_u->zbd_put_io
pointer is NULL.

ASYNC I/O engine case (e.g. io_uring):
The zone will be locked by zbd_adjust_block(), td->io_ops->queue(td, io_u),
which for an async I/O engine will return FIO_Q_QUEUED.

This return value will be send in to zbd_queue_io_u(), which at the end
of the function, unlocks the zone if the return value from ->queue()
differs from FIO_Q_QUEUED. For an async I/O engine, the zone will not be
unlocked here, so the io_u->zbd_put_io function pointer will still be set.

io_uring does implement the ->commit() callback, so it will not call
zbd_put_io_u() here at all.

Instead zbd_put_io_u() will be called by do_io() -> wait_for_completions()
-> io_u_queued_complete() -> ios_completed() -> put_io_u() -> zbd_put_io_u(),
which will unlock the zone and will set the io_u->zbd_put_io function pointer
to NULL.

In conclusion, the zbd_put_io_u() should never had been added in the case
where the ->commit() callback wasn't implemented in the first place,
and removing it shouldn't affect ioengines psync or io_uring.

Commit d9ed3e63e528 ("zbd: Fix zone locking for async I/O engines")
probably made the assumption that an async I/O engine == the ->commit()
callback is implemented, however, this is not true, there are async
I/O engines in tree (and out of tree), that does not implement the
->commit() callback. Instead, an async I/O engine is recognized by
the ->queue() callback returning FIO_Q_QUEUED.

Removing the invalid zbd_put_io_u() call will ensure that a zone is not
prematurely unlocked for async I/O engines that do not implement the
->commit() callback. Unlocking a zone prematurely leads to I/O errors.

Fixes: d9ed3e63e528 ("zbd: Fix zone locking for async I/O engines")
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

The GPL isn't a EULA: remove it and introduce WixUI_Minimal_NoEULA

The GPL shouldn't be used as a EULA in an installer.
Remove it, and since the WixUI_Minimal dialog set requires a EULA
create a custom WixUI_Minimal_NoEULA set.

Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Merge branch 'pthread_getaffinity_1' of https://github.com/kusumi/fio

* 'pthread_getaffinity_1' of https://github.com/kusumi/fio:
  gettime: Fix compilation on non-Linux with pthread_getaffinity_np()

gettime: Fix compilation on non-Linux with pthread_getaffinity_np()

874d55e50c("os/os-linux: add pthread CPU affinity helper") and a few
commits after that broke compilation on non-Linux platforms which support
pthread_getaffinity_np().

Define fio_get_thread_affinity() on non-Linux platforms, and make gettime
test FIO_HAVE_GET_THREAD_AFFINITY which may or may not depend on pthread.
FIO_HAVE_GET_THREAD_AFFINITY is currently not defined on Windows.

Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@gmail.com>

Merge branch 'gpspm-add-optional-use-rpma_conn_completion_wait-function' of https://github.com/ldorau/fio

* 'gpspm-add-optional-use-rpma_conn_completion_wait-function' of https://github.com/ldorau/fio:
  rpma: gpspm: introduce the busy_wait_polling toggle

rpma: gpspm: introduce the busy_wait_polling toggle

The performance of the librpma_gpspm engine depends heavily
on how much CPU power it can use to its work.
One can want either to take all available CPU power
and see what the maximum possible performance is
or configure it less aggressively and collect the results
when the CPU is not solely dedicated to doing this one task.

The librpma_gpspm engine allows toggling between one and another
by either waiting for incoming requests in the kernel
using rpma_conn_completion_wait() (busy_wait_polling=0)
or trying to collect the completion as soon as it appears
by polling all the time using rpma_conn_completion_get()
(busy_wait_polling=1).

Signed-off-by: Oksana Salyk <oksana.salyk@intel.com>

Merge branch 'zbd-no-parallel-init' of https://github.com/floatious/fio

* 'zbd-no-parallel-init' of https://github.com/floatious/fio:
  init: zonemode=zbd does not work with create_serialize=0

init: zonemode=zbd does not work with create_serialize=0

zbd_init_zone_info() has a comment that it only works correctly if it
called before the first fio fork() call.
However, right now, there is nothing that ensures this.

If the user specifies --create_serialize=0 and --numjobs=2, each thread
will get their own version of zbd_info.

zbd_info contains one mutex per zone, so if the threads get different
zbd_info, two threads can manage to lock the same zone at the same time,
which will lead to I/O errors.

Explicitly disallow --zonemode=zbd together with --create_serialize=0,
so that we know that all threads will use the same zbd_info, instead of
silently misbehaving.

Analysis:
setup_files() calls zbd_init_files() which calls zbd_init_zone_info().
zbd_init_zone_info() does a for_each_td(), where it checks if zbd_info
(for the same filename) has already been allocated by another thread.
This only works if create_serialize=1 (default).
If create_serialize=0, zbd_init_zone_info() will get called in parallel,
and in this case when the second thread checks if any other thread has
allocated zbd_info, the check will fail, since the first thread has not
yet been running long enough to allocate zbd_info.

Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>

NFS configure fixes

backend: fix switch_ioscheduler()

The backend.c function switch_ioscheduler() suffers from several
problems:
1) This function only considers the first file of a job. For jobs using
   multiple files, the ioscheduler switch will done only for that file.
2) If the job file is a character device, a pipe or a regular file for
   which the hosting block device file cannot be determined (e.g. a
   remote file), thring to switch the IO scheduler causes a crash as the
   file disk_util field is NULL.
Fix both problems by introducing the helper function set_ioscheduler()
and changing switch_ioscheduler() to repeatdly call this helper for all
files of the job, ignoring character device files, pipe files and files
without a hosting device information.

Also update the man page to better explain when the ioscheduler option
applies.

Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

engines: add engine for file delete

This engine is to measure the performance of deleting files.

In practice, it is an important benchmark for a file system that
how quick it can release the disk space of deleted files.

Signed-off-by: friendy-su <friendy.su@sony.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Merge branch 'parse-signedness-warn' of https://github.com/floatious/fio

* 'parse-signedness-warn' of https://github.com/floatious/fio:
  parse: fix parse_is_percent() warning

parse: fix parse_is_percent() warning

When compiling an out of tree ioengine, such as the SPDK fio plugin,
which has -Wextra in CFLAGS, the compiler gives the following warning:

parse.h: In function ‘parse_is_percent’:
parse.h:134:13: warning: comparison of integer expressions of different signedness: ‘long long unsigned int’ and ‘int’ [-Wsign-compare]

Since this warning was introduced recently by fio
commit b75c0fae6612 ("parse: simplify parse_is_percent()"),
and since this is the only warning seen when compiling the SPDK fio
plugin, readd the ULL prefix to parse_is_percent().

Fixes: b75c0fae6612 ("parse: simplify parse_is_percent()")
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>

engines/libpmem: do not call drain on close

no matter if direct was 1 or 0, it's not necessary.
It's either covered by non-temporal stores or it's not desired
by user (if 0 was set).

Signed-off-by: Łukasz Stolarczuk <lukasz.stolarczuk@intel.com>

engines/libpmem: cleanup a little code, comments and example

Signed-off-by: Łukasz Stolarczuk <lukasz.stolarczuk@intel.com>

engines/libpmem: set file open/create mode always to RW

previously, when created file with a 'write' job it couldn't be open
later on, when a 'read' job was ran.

Signed-off-by: Łukasz Stolarczuk <lukasz.stolarczuk@intel.com>

NFS engine

t/zbd: test repeated async write with block size unaligned to zone size

A recently fixed bug was caused by zone reset during asynchronous IOs
in-flight. The bug symptom was unaligned command error which was
observed using random write workload with libaio engine and block size
not a divisor of zone size. To confirm the bug fix and to prevent future
regression, add a test case which runs the workload.

Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

zbd: avoid zone reset during asynchronous IOs in-flight

When fio repeats same workload on zoned block devices, zbd_file_reset()
is called for each repetition. This function resets target zones when
one of two conditions are met: 1) the write pointer of the zone has
offset from the device start unaligned to block size, or 2) the workload
is verify and verification is not in process. When the workload runs
with block size not a divisor of the zone size, the offsets of write
pointers from device start (not from zone start) become unaligned to
block size, then zbd_file_reset() resets target zones. This zone reset
happens even when the asynchronous IOs are in-flight and causes
unexpected IO results. Especially if write requests are in-flight, they
fail with unaligned write command error. A single thread may do both the
zone reset and the write request submit, recursive zone locks can not
prevent the zone reset during the writes.

The write pointer check for block size alignment is not working as
intended. It should have checked offset not from device start but from
zone start. Having said that, regardless of this write pointer check
correctness, the zone reset is not required since the zones are reset in
zbd_adjust_block() anyway when remainder of the zone between write
pointer and zone end is smaller than block size.

To avoid the zone reset during asynchronous IOs, do not reset zones in
zbd_file_reset() when the write pointer offset from the device start is
unaligned to block size. Modify zbd_file_reset() to call the helper
function zbd_reset_zones() only when the workload is verify and
verification is not in process. The function zbd_reset_zones() had an
argument 'all_zones' to inform that the zones should be reset when its
write pointer is unaligned to block size. This argument is not required.
Remove it and simplify the function accordingly.

The zone reset for verify workloads is still required. It does not
conflict with asynchronous IOs, since fio waits for IO completion at
verification end, then IOs are not in-flight when zbd_file_reset() is
called for repetition after verification.

Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>

Merge branch 'wip-rados-dont-zerowrite' of https://github.com/aclamk/fio

* 'wip-rados-dont-zerowrite' of https://github.com/aclamk/fio:
  engine/rados: Add option to skip object creation

gettime: cleanup ifdef mess

Let's just set mask to all CPUs for the non-affinity case, and we
can use the same mask test case throughout.

Signed-off-by: Jens Axboe <axboe@kernel.dk>

gettime: check affinity for thread, if we have it

If we have fio_get_thread_affinity(), we can support a smaller
(and sparse) CPU mask for the clock test.

Signed-off-by: Jens Axboe <axboe@kernel.dk>

os/os-linux: add pthread CPU affinity helper

Signed-off-by: Jens Axboe <axboe@kernel.dk>

configure: add test case for pthread_getaffinity_np()

Signed-off-by: Jens Axboe <axboe@kernel.dk>

Merge branch 'unified-merge' of https://github.com/jeffreyalien/fio

* 'unified-merge' of https://github.com/jeffreyalien/fio:
  Add functionality to the unified_rw_reporting parameter to output separate and mixed stats when set to 'both' or 2.

Add functionality to the unified_rw_reporting parameter to output
separate and mixed stats when set to 'both' or 2.

To achieve this, the stats are gathered on a per/data direction
(read/write/etc) basis and then summed into the mixed stats when
generating output.

This functionality also allows setting unified_rw_reporting to
'none' or 'mixed' instead of 0 or 1 respectively.

Signed-off-by: Brandon Paupore <brandon.paupore@wdc.com>
Co-authored-by: Jeff Lien <jeff.lien@wdc.com>

Merge branch 'add-librpma-engines' of https://github.com/janekmi/fio

* 'add-librpma-engines' of https://github.com/janekmi/fio:
  rpma: add librpma_apm_* and librpma_gpspm_* engines

Merge branch 'free-dump-options' of https://github.com/floatious/fio

* 'free-dump-options' of https://github.com/floatious/fio:
  options: free dump options list on exit

Merge branch 'patch-1' of https://github.com/ihsinme/fio

* 'patch-1' of https://github.com/ihsinme/fio:
  fix loop with unreachable exit condition

Merge branch 'dfs_engine' of https://github.com/johannlombardi/fio

* 'dfs_engine' of https://github.com/johannlombardi/fio:
  engines/dfs: add DAOS File System (dfs) engine
  Disable pthread_condattr_setclock on cygwin

engines/dfs: add DAOS File System (dfs) engine

DAOS is a new scale-out open-source object store.
See https://github.com/daos-stack/daos for more information.

This patch adds a new fio engine to support the filesystem layer built
on top of DAOS called DFS (DAOS File System). It supports asynchronous
read/write operations.

Signed-off-by: Johann Lombardi <johann.lombardi@intel.com>
Co-authored-by: Mohamad Chaarawi <mohamad.chaarawi@intel.com>
Co-authored-by: Vishwanath Venkatesan <vishwanath.venkatesan@intel.com>
Co-authored-by: Ioannis Galanis <ioannis.galanis@intel.com>

Disable pthread_condattr_setclock on cygwin

Signed-off-by: Johann Lombardi <johann.lombardi@intel.com>

rpma: add librpma_apm_* and librpma_gpspm_* engines

The Remote Persistent Memory Access (RPMA) Library is a C library
created to simplify accessing persistent memory on remote hosts over
Remote Direct Memory Access (RDMA).

The librpma_apm_client and librpma_apm_server is a pair of engines
which allows benchmarking persistent writes achieved via
the Appliance Persistency Method (APM; natively supported by
the librpma library) and regular reads (a part of the RDMA standard).

The librpma_gpspm_client and librpma_gpspm_server is a pair of
engines which allows benchmarking persistent writes achieved via
the General Purpose Persistency Method (GPSPM; build on top of
the librpma API).

The librpma library is available here: https://github.com/pmem/rpma
along with the set of scripts using the newly introduced engines
to construct miscellaneous benchmarking scenarios:
https://github.com/pmem/rpma/tree/master/tools/perf

The full history of the development of the librpma fio engines
is available at: https://github.com/pmem/fio/tree/rpma

Co-Authored-By: Lukasz Dorau <lukasz.dorau@intel.com>
Co-Authored-By: Tomasz Gromadzki <tomasz.gromadzki@intel.com>
Co-Authored-By: Jan Michalski <jan.m.michalski@intel.com>
Co-Authored-By: Oksana Salyk <oksana.salyk@intel.com>

Merge branch 'dev_luye_github' of https://github.com/louisluSCU/fio

* 'dev_luye_github' of https://github.com/louisluSCU/fio:
  Fix reading multiple blktrace replay files