> -----Original Message-----
> From: Alexey Dobriyan <adobriyan@xxxxxxxxx>
> Sent: Wednesday, August 19, 2020 8:56 AM
> To: Dmitry Fomichev <Dmitry.Fomichev@xxxxxxx>
> Cc: fio@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH] zbd: remove reset_zone flag from fio_zone_info
>
> > The reset_zone flag that is defined in fio_zone_info structure is
> > only referenced in zbd_adjust_block() function. Convert this flag
> > to a local variable and save some room in zbd_info array which can
> > be pretty large when running fio against high capacity zoned devices.
>
> This flag should be kept.
>
> Test can crash or be interrupted leaving hw in indeterminate state,
> it must be restarted from clean state. Or test can be precondition and
> zone should not be reset.
This is beyond the scope of fio. Any preconditioning of zones is done
by external scripts that have no access to this flag. Tools like blkzone,
libzbc or nvme-cli are typically used to precondition zones before
testing and to analyze zone state after test runs.
>
> Can't distinguish these two cases from write pointers alone.
>
> Given that precondition and real workload can be in different fio
> instances, this information must be somehow given to fio process
> and either force or not force zone reset (config option obviously)
The functionality you are describing in not a part of the current fio code.
Perhaps you are talking about some proprietary code additions that you
are developing. Please submit a patch that will implement what you are
talking about and if it has merit you will have a solid case to reintroduce
this flag.
For now, having this flag only makes the code less straightforward.
>
> > @@ -41,7 +40,6 @@ struct fio_zone_info {
> > enum zbd_zone_type type:2;
> > enum zbd_zone_cond cond:4;
> > unsigned int open:1;
> > - unsigned int reset_zone:1;
>
> Does it save space? Bitfields stick together after all.
It saves room for other stuff that is going be added to this struct in the
future. Some new members will likely be added there to support zone
append and there is some other development in the works that will likely
add more bits there. Keep in mind that the number of zones on a 20TB
DHSMR drive may exceed 130K and these numbers will only grow
over time. Every bit counts in this structure :)
