On Tue, 2022-11-08 at 17:49 +0900, Shin'ichiro Kawasaki wrote:
> When zone_reset_threshold and zone_reset_frequency options are specified
> with zonemode=zbd, it resets zones not full. When verify option is
> specified on top of that, the zone reset of non-full zones erases data
> for verify and causes verify failure. Current implementation avoids this
> scenario by assert.
>
> To allow zone_reset_threshold/frequency options together with verify,
> do verify before the zone reset. When zone reset is required to an open
> zone with verify data, call get_next_verify() to get io_u for verify
> read and return it from zbd_adjust_block(). When io_u->file is set,
> get_next_verify() assumes the io_u is requeued and does nothing. Unset
> io_u->file to tell get_next_verify() is not requeued.
>
> Also modify verify_io_u() to skip rand_seed check when the option
> zone_reset_frequency is set. When the option is set, random seed is not
> reset for verify reads in same manner as verify_backlog option, then
> this check is not valid.
>
> Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@xxxxxxx>
Hi Shin'ichiro,
Yesterday, I encountered a test failure with the version 2 of this patch.
When I create a /dev/nullb using this command -
modprobe null_blk nr_devices=1 zoned=1 zone_size=16 memory_backed=1
and run t/zbd/test-zbd-support /dev/nullb0 against this device, the test #34
fails with verification errors:
verify: bad magic header ffff, wanted acca at file /dev/nullb0 offset 33554432,
length 28672 (requested block: offset=33554432, length=28672)
verify: bad magic header ffff, wanted acca at file /dev/nullb0 offset 50331648,
length 28672 (requested block: offset=50331648, length=28672)
verify: bad magic header ffff, wanted acca at file /dev/nullb0 offset 16777216,
length 28672 (requested block: offset=16777216, length=28672)
I was hoping that v4 will fix this issue, but it is still happening in my
testing. Setting zone_size to any other value or setting zone_capacity to a value
other than zone_size makes the test run without an error. This is very peculiar.
I wonder if you can reproduce this failure...
DF
> ---
> verify.c | 6 ++++--
> zbd.c | 14 +++++++++++++-
> 2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/verify.c b/verify.c
> index d6a229ca..ddfadcc8 100644
> --- a/verify.c
> +++ b/verify.c
> @@ -917,9 +917,11 @@ int verify_io_u(struct thread_data *td, struct io_u
> **io_u_ptr)
> hdr = p;
>
> /*
> - * Make rand_seed check pass when have verify_backlog.
> + * Make rand_seed check pass when have verify_backlog or
> + * zone reset frequency for zonemode=zbd.
> */
> - if (!td_rw(td) || (td->flags & TD_F_VER_BACKLOG))
> + if (!td_rw(td) || (td->flags & TD_F_VER_BACKLOG) ||
> + td->o.zrf.u.f)
> io_u->rand_seed = hdr->rand_seed;
>
> if (td->o.verify != VERIFY_PATTERN_NO_HDR) {
> diff --git a/zbd.c b/zbd.c
> index 6f4e5ab2..fadeb458 100644
> --- a/zbd.c
> +++ b/zbd.c
> @@ -2032,7 +2032,19 @@ retry:
>
> /* Reset the zone pointer if necessary */
> if (zb->reset_zone || zbd_zone_full(f, zb, min_bs)) {
> - assert(td->o.verify == VERIFY_NONE);
> + if (td->o.verify != VERIFY_NONE) {
> + /*
> + * Unset io-u->file to tell get_next_verify()
> + * that this IO is not requeue.
> + */
> + io_u->file = NULL;
> + if (!get_next_verify(td, io_u)) {
> + zone_unlock(zb);
> + return io_u_accept;
> + }
> + io_u->file = f;
> + }
> +
> /*
> * Since previous write requests may have been
> submitted
> * asynchronously and since we will submit the zone
