Re: ZBC/FLEX FIO addition ideas

[Bart Van Assche <Bart.VanAssche@wdc.com>]

On Thu, 2018-03-15 at 12:06 -0600, Phillip Chen wrote:
> Would creating new profiles for all the I/O patterns be particularly
> difficult? I'm sure you're much more familiar with the FIO codebase
> than I am, but it seems to me that all you'd need to do for randoms is
> move the logic from the zbc_adjust_block cases upstream into the
> various methods called by get_off_from_method(), or possibly modify
> the existing methods to work differently when working on a ZBC drive.
> For sequentials it seems like you'd just have to move the logic into
> get_next_seq_offset().

Hello Phillip,

Adding support for ZBC drives through creation of a new profile has the
following disadvantages:
- It makes it impossible to use another profile (act or tiobench) for the
  generation of a workload.
- It will lead to code duplication. fio already has code for supporting a
  large number of I/O patterns (sequential, random, ...). If we can avoid
  code duplication I think we should avoid it.

> It also seems to me that it might be better to have get_next_block()
> pick a valid area to begin with.

What does "valid" mean in this context? Have you noticed that
zbc_adjust_block() modifies the I/O request offset and length such that
neither write errors nor reads past the end of the write pointer are
triggered?

> The main benefit to doing this that I
> can see would be to allow much more control over the number of open
> zones, which I think will be of particular interest in testing ZBC
> drive performance. Additionally, it might be worthwhile to have an
> option allows the workload to pick a new zone instead of resetting the
> write pointer of a zone when writing to a full zone. This would also
> be made easier with a more upstream approach, because you wouldn't
> need to retry and get a new offset, you could just avoid full zones
> entirely. Or you could keep track of which zones are open and
> add/replace open zones as necessary.

With the approach I proposed it is already possible to control the number of
open zones, namely by setting the I/O offset (--offset=) to the start of a
zone and by setting the I/O size (--io_size=) to (number of zones to test) *
(zone size). But I agree with you that the kind of workload that you
described would best be implemented as an I/O profile. How about starting
with the approach I proposed and adding profile(s) for more advanced ZBC I/O
patterns later?

Thanks,

Bart.