linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "mb@lightnvm.io" <mb@lightnvm.io>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	"loberman@redhat.com" <loberman@redhat.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	Damien Le Moal <Damien.LeMoal@wdc.com>
Subject: Re: Zoned block device support for fio (was: [PATCH 0/2] null_blk: zone support)
Date: Thu, 9 Aug 2018 20:51:50 +0000	[thread overview]
Message-ID: <8d1946fb8f46c66b572a7643d47f9762154d1e8b.camel@wdc.com> (raw)
In-Reply-To: <be88923a-b960-0786-bd21-a4107cccd834@kernel.dk>

On Tue, 2018-07-10 at 12:51 -0600, Jens Axboe wrote:
> On 7/10/18 12:49 PM, Bart Van Assche wrote:
> > On Tue, 2018-07-10 at 12:45 -0600, Jens Axboe wrote:
> > > The difference between the job file and the
> > > workload run can be huge. Consider something really basic:
> > > 
> > > [randwrites]
> > > bs=4k
> > > rw=randwrite
> > > 
> > > which would be 100% random 4k writes. If I run this on a zoned device,
> > > then that'd turn into 100% sequential writes.
> > 
> > That's not correct. The ZBD code in the github pull request serializes writes
> > per zone, not globally.
> 
> That's a totally minor detail. If all my random writes fall within a single
> zone, then they'd be 100% sequential. For N open zones, you'd be 100%
> sequential within the zone. The point is that the workload as defined and
> the workload as run are two totally different things, and THAT is the
> problem.

Hello Jens,

What you proposed in a previous e-mail, namely to use the existing fio zone
concept for zoned block devices sounds interesting to me. This is something I
will definitely look further into. This will help to make a given workload
that is suited for zoned block devices to behave (almost) identical when run
against a regular block device. Since fio users expect that no zones are
reset before e.g. a random write test is started, there will always be a small
difference in behavior between a workload run against a zoned block device and
a workload run against a regular device if some zones already contain data.

It's not clear to me how close you want the behavior of fio to be for zoned
and regular block devices. Do you e.g. want me to introduce a new I/O pattern
(--rw=...) that causes fio to write sequentially inside a zone and for which
zones are selected randomly? I don't see any other approach that allows to
make sure that the same workload definition behaves identically against zoned
and regular block devices.

Thanks,

Bart.


  reply	other threads:[~2018-08-09 20:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-06 17:38 [PATCH 0/2] null_blk: zone support Matias Bjørling
2018-07-06 17:38 ` [PATCH 1/2] null_blk: move shared definitions to header file Matias Bjørling
2018-07-06 17:38 ` [PATCH 2/2] null_blk: add zone support Matias Bjørling
2018-07-06 17:45 ` [PATCH 0/2] null_blk: " Laurence Oberman
2018-07-09  7:54   ` Matias Bjørling
2018-07-09 16:34     ` Jens Axboe
2018-07-10  0:05       ` Bart Van Assche
2018-07-10 14:46         ` Jens Axboe
2018-07-10 16:47           ` Bart Van Assche
2018-07-10 18:45             ` Jens Axboe
2018-07-10 18:49               ` Bart Van Assche
2018-07-10 18:51                 ` Jens Axboe
2018-08-09 20:51                   ` Bart Van Assche [this message]
2018-08-09 21:03                     ` Zoned block device support for fio Jens Axboe
2018-08-15 18:07                       ` Bart Van Assche
2018-07-07  2:54 ` [PATCH 0/2] null_blk: zone support Jens Axboe

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=8d1946fb8f46c66b572a7643d47f9762154d1e8b.camel@wdc.com \
    --to=bart.vanassche@wdc.com \
    --cc=Damien.LeMoal@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loberman@redhat.com \
    --cc=mb@lightnvm.io \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).