On Mon, Apr 20, 2020 at 02:41:06AM +0000, Damien Le Moal wrote: > On 2020/04/18 2:31, Alexey Dobriyan wrote: > > On Fri, Apr 17, 2020 at 08:32:05AM -0600, Jens Axboe wrote: > >> I'm not a huge fan of this zbd sprinkling everywhere, but that's not the > >> fault of your fix. But I would really prefer if zbd got disentangled > >> from the core/hot paths completely, maybe by adding a io engine fn for > >> whatever it needs to do. > > > > I think it should be done at generator level. zonemode=strided/zbd is > > really a specialized random generator. Such generator would issue first > > write in ZBD mode and read/write in normal mode. > > > > zbd_adjust_block() is strange. For example "norandommap" in ZBD mode > > doesn't guarantee full LBA space coverage even with 1 thread but it > > would guarantee it with 1 thread and generator which shuffles zone > > numbers once and issues writes with any QD. > > I do not understand your point here: norandommap does *not* guarantee full block > space coverage at all, no matter the zonemode=xxx or no zonemode. For guaranteed > full block space coverage, norandommap should not be specified so that fio keeps > the history of past accesses, no ? I always forget which one is which. Right now adjusting in zbd_adjust_block() doesn't guarantee full LBA space coverage in cases where deleting "zonemode=" would have done it, even with 1 thread: [global] filename=/dev/loop0 # 1GB direct=1 zonemode=zbd zonesize=1M randseed=1 thread bs=256K rw=randwrite ioengine=libaio iodepth=1 [j] max_open_zones=1 size=27M t 1 ZR 1 t 1 ZR 2 t 1 ZR 3 t 1 ZR 4 t 1 ZR 5 t 1 ZR 6 t 1 ZR 7 t 1 ZR 8 t 1 ZR 9 t 1 ZR 10 t 1 ZR 11 t 1 ZR 12 t 1 ZR 13 t 1 ZR 14 t 1 ZR 15 t 1 ZR 16 t 1 ZR 17 t 1 ZR 18 t 1 ZR 19 t 1 ZR 20 t 1 ZR 21 t 1 ZR 22 t 1 ZR 22 <=== t 1 ZR 23 t 1 ZR 24 t 1 ZR 25 t 1 ZR 26 Non-randomness is separate bug -- "z++" in zbd_convert_to_open_zone().
