All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Puthikorn Voravootivat <puthik@chromium.org>
Cc: FIO List <fio@vger.kernel.org>,
	Gwendal Grignou <gwendal@chromium.org>,
	Grant Grundler <grundler@chromium.org>
Subject: Re: [PATCH] fix rand_seed mismatches in verify phase
Date: Wed, 5 Feb 2014 10:15:28 -0700	[thread overview]
Message-ID: <20140205171528.GF27534@kernel.dk> (raw)
In-Reply-To: <1391463077-14292-1-git-send-email-puthik@chromium.org>

On Mon, Feb 03 2014, Puthikorn Voravootivat wrote:
> In verify phase, the rand_seed generated on replay does not match
> the written rand_seed.
> 
> Multiple problems are causing this:
> 1. In verify phase fio does not set io_u->rand_seed to compare with
>    hdr->rand_seed
> 2. In randrw scenario, fio log is stored in red-black tree in "sorted by LBA"
>    order.  Thus, it is imposible to replay the written order, or rather
>    generate the seeds again in the same order.
> 3. In write phase, the code currently will generate rand_seed, write data
>    and log rand_seed. When queuedepth > 1, it's possible the writes complete
>    in a different order than rand_seed was generated.  Thus when replaying
>    the log, the generated rand_seed might not match what was written.
> 4. verify_backlog option will start verification before all the data has been
>    written and it make rand_seed replay code broken with current design.
> 
> Proposed fixes:
> 1. Use of existing verify_state to generate verify header.
>    (and assumes this was the original intention of verify_state). And also
>    adds code to replay rand_seed in verify phase.
> 2. If verifysort option is not enabled, store the write log in a list instead
>    of the red-black tree. Otherwise, don't attempt to verify the rand_seed
>    in the header.
> 3. In write phase,  generate rand_seed, log rand_seed, write data. I.e. log
>    IO transactions in the order generated, not completed.
> 4. Don't verify rand_seed when verify_backlog is enabled.

Seems like a reasonable solution to it all. Thanks! I'll get this
applied.

-- 
Jens Axboe



  parent reply	other threads:[~2014-02-05 17:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-03 21:31 [PATCH] fix rand_seed mismatches in verify phase Puthikorn Voravootivat
2014-02-03 22:54 ` Grant Grundler
2014-02-04 18:54   ` Puthikorn Voravootivat
2014-02-04 19:21     ` Grant Grundler
2014-02-05 18:27     ` Jens Axboe
2014-02-05 18:31       ` Grant Grundler
2014-02-05 19:30         ` Jens Axboe
2014-02-05 21:31           ` Grant Grundler
2014-02-05 21:38             ` Jens Axboe
2014-02-04 18:56   ` Puthikorn Voravootivat
2014-02-05 17:15 ` Jens Axboe [this message]
2014-02-05 18:16   ` Grant Grundler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140205171528.GF27534@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=fio@vger.kernel.org \
    --cc=grundler@chromium.org \
    --cc=gwendal@chromium.org \
    --cc=puthik@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.