lkml.org 
[lkml]   [2018]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 0/2] null_blk: zone support
Date
On Tue, 2018-07-10 at 08:46 -0600, Jens Axboe wrote:
> On 7/9/18 6:05 PM, Bart Van Assche wrote:
> > On Mon, 2018-07-09 at 10:34 -0600, Jens Axboe wrote:
> > > 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.
> >
> > 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 main issue I have with that approach is that the core of fio is
> generating the IO patterns, and then you are just changing them as you
> see fit. This means that the workload definition and the resulting IO
> operations are no longer matched up, since they now also depend on what
> you are running on. If I take one workload and run it on a zoned drive,
> and then run it on a non-zoned drive, I can't compare the results at
> all. This is a showstopper.
>
> There should be no adjusting of the output, rather it should be possible
> to write zoned friendly job definitions. It should be possible to run
> the same job on a non-zoned drive, and vice versa, and the resulting IO
> patterns must be the same.
>
> Fio already has some notion of zones. Maybe that could be extended to
> hard zones, and some control of open zones, and patterns within those
> zones?

Hello Jens,

How about adding a job option that makes it possible to use the zoned
block device (ZBD) I/O pattern on non-ZBD devices, requiring that the
zone size is set explicitly for non-ZBD devices and maintaining a write
pointer not only when performing I/O to a ZBD device but also if a
ZBD-style I/O pattern is applied to a non-ZBD disk? This should allow to
apply exactly the same workload to a non-ZBD disk as to a ZBD disk.

What I derived from the fio source code is as follows (please correct me
if I got anything wrong):
* The purpose of the zonesize, zonerange and zoneskip job options is to
limit the I/O range to a single zone with size "zonesize". The I/O
pattern for zoned block devices is different: I/O happens in multiple
zones simultaneously. The number of zones to which I/O happens is
called the number of open zones.
* The purpose of the random_distribution=zoned{_abs} job option is to
allow the user to skew a uniform random distribution. This is another
workload pattern than the typical pattern for ZBD drives.

Thanks,

Bart.





\
 
 \ /
  Last update: 2018-07-10 18:48    [W:0.250 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site