archive mirror
 help / color / mirror / Atom feed
From: Bart Van Assche <>
To: "" <>,
	"" <>,
	"" <>
Cc: "" <>,
	"" <>,
	Damien Le Moal <>
Subject: Re: [PATCH 0/2] null_blk: zone support
Date: Tue, 10 Jul 2018 00:05:38 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, 2018-07-09 at 10:34 -0600, Jens Axboe wrote:
> On 7/9/18 1:54 AM, Matias Bjørling wrote:
> > For fio, you can use the zone support here:
> > 
> >
> > 
> > It is in the process of being upstreamed.
> In the spirit of making some progress on this, I just don't like how
> it's done. For example, it should not be necessary to adjust what
> comes out of the block generator, instead the block generator should
> be told to do what we need on zbc. This is a key concept. The workload
> should be defined as such that it works for zoned devices.

Hello Jens,

How would you like to see block generation work? I don't see an alternative
for random I/O other starting from the output of a random generator and
translating that output into something that is appropriate for a zoned block
device. Random reads must happen below the zone pointer if fio is configured
to read below the zone pointer. Random writes must happen at the write
pointer. The only way I see to implement such an I/O pattern is to start
from the output of a random generator and to adjust the output of that
random generator. However, I don't have a strong opinion whether adjusting
the output of a random generator should happen by the caller of
get_next_buflen() or inside get_next_buflen(). Or is your concern perhaps
that the current approach interferes with fio job options like bs_unaligned?

> The trim as zone resets seems odd. What happens if you end up with a
> zoned flash device in the future?

We can leave out the code that translates trim into zone resets from fio
and discuss later how to handle this. One possibility is to modify the sd
driver such that it translates REQ_OP_DISCARD into zone resets when
appropriate. There may be better alternatives.


  reply	other threads:[~2018-07-10  0:05 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 [this message]
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                   ` Zoned block device support for fio (was: [PATCH 0/2] null_blk: zone support) Bart Van Assche
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:

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

  git send-email \ \ \ \ \ \ \ \ \

* 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).