Re: [PATCH v2 1/2] block: add max_open_zones to blk-sysfs

[Johannes Thumshirn <Johannes.Thumshirn@wdc.com>]

On 03/07/2020 11:23, Niklas Cassel wrote:
> On Fri, Jul 03, 2020 at 08:22:45AM +0000, Johannes Thumshirn wrote:
>> On 02/07/2020 20:20, Niklas Cassel wrote:
>>> Documentation/block/queue-sysfs.rst |  7 +++++++
>>>  block/blk-sysfs.c                   | 15 +++++++++++++++
>>>  drivers/nvme/host/zns.c             |  1 +
>>>  drivers/scsi/sd_zbc.c               |  4 ++++
>>>  include/linux/blkdev.h              | 16 ++++++++++++++++
>>>  5 files changed, 43 insertions(+)
>>
>> Sorry I haven't noticed before, but you forgot null_blk.
> 
> Hello Johannes,
> 
> Actually, I haven't forgotten about null_blk :)
> 
> The problem with null_blk is that, compared to these simple patches that
> simply exposes the Max Open Zones/Max Active Zones, null_blk additionally
> has to keep track of all the zone accounting, and give an error if any
> of these limits are exceeded.
> 
> null_blk right now follows neither the ZBC nor the ZNS specification
> (even though it is almost compliant with ZBC). However, since null_blk
> is really great to test with, we want it to support Max Active Zones,
> even if that concept does not exist in the ZBC standard.
> 
> To add to the problem, open() does not work exactly the same in ZBC and
> ZNS. In ZBC, the device always tries to close an implicit zone to make
> room for an explicit zone. In ZNS, a controller that doesn't do this is
> fully compliant with the spec.
> 
> So now for null_blk, you have things like zones being implicit closed when
> a new zone is opened. And now we will have an additional limit (Max Active
> Zones), that we need to consider before we can even try to close a zone.
> 
> 
> I've spent a couple of days trying to implement this already, and I think
> that I have a way forward. However, considering that vacations are coming
> up, and that I have a bunch of other stuff that I need to do before then,
> I'm not 100% sure that I will be able to finish it in time for the coming
> merge window.
> 
> Therefore, I was hoping that we could merge this series as is, and I will
> send out the null_blk changes when they are ready, which might or might
> not make it for this merge window.

No problem, I'm just working on MOR support for zonefs and though about how
I'm going to test it. This is where I've noticed null_blk doesn't really 
expose a config knob for MOR. I can do some temporary hacks to test my changes
and wait for your's to materialize. 


> In the meantime, MAR/MOR properties for null_blk will be exposed as 0,
> which means "no limit". (Which is the case when a zoned block device driver
> doesn't do an explicit call to blk_queue_max_{open,active}_zones()).