Re: [PATCH 02/12] zbd: set norandommap=1 when zonemode=zbd is specified

On Thu, Jan 8, 2026 at 9:36 PM Shin'ichiro Kawasaki
<[email protected]> wrote:
>
> The random map functionality relies on the minimum block size to manage
> the map of written blocks, in order to ensure that all blocks are
> written with a random workload. This is normally fine, but in the case
> of a zoned block devices being written with a minimum block size that is
> not aligned with the zone size or the write pointer position at workload
> start, the last blocks of a zone can only be written using a write
> operation with a size smaller than the minimum block size. This
> conflicts with the random map operation.
>
> In preparation for supporting writing a zone remainder smaller than the
> minimum block size without using a zone finish operation, disable the
> random map feature by setting norandommap=1 when zonemode=zbd is
> specified.
>
> Signed-off-by: Shin'ichiro Kawasaki <[email protected]>
> ---
>  init.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>
> diff --git a/init.c b/init.c
> index 76e1a86d..9320bca8 100644
> --- a/init.c
> +++ b/init.c
> @@ -665,6 +665,19 @@ static int fixup_options(struct thread_data *td)
>                 ret |= 1;
>         }
>
> +       if (o->zone_mode == ZONE_MODE_ZBD) {
> +               if (fio_option_is_set(o, norandommap)) {
> +                       if (o->norandommap == 0) {
> +                               log_err("fio: zonemode=zbd requires norandommap=1\n");
> +                               ret |= 1;
> +                       }
> +                       /* if == 1, OK */
> +               } else {
> +                       dprint(FD_ZBD, "fio: zonemode=zbd sets norandommap=1\n");
> +                       o->norandommap = 1;
> +               }
> +       }
> +
>         if (o->zone_mode == ZONE_MODE_STRIDED && !o->zone_size) {
>                 log_err("fio: --zonesize must be specified when using --zonemode=strided.\n");
>                 ret |= 1;
> --
> 2.49.0
>

As you know, we try to avoid breaking existing job files. This change
breaks 3 test cases.
Fixing a genuine bug or clarifying previously undefined behavior can
justify this sort of breaking change.

It seems heavy handed to suddenly prohibit running a test on a zoned
block device with a random map. Can you provide a stronger
justification for this change?

Perhaps you could instead emit a warning when a random job is run with
a random map and then condition the relevant changes in later patches
on the absence of a random map.

Vincent