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: > > > > https://github.com/bvanassche/fio > > > > 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. Bart.
