On Fri, Jun 26, 2020 at 01:14:30AM +0000, Damien Le Moal wrote: > As long as you keep ZNS namespace report itself as being "host-managed" like > ZBC/ZAC disks, we need the consistency and common interface. If you break that, > the meaning of the zoned model queue attribute disappears and an application or > in-kernel user cannot rely on this model anymore to know how the drive will behave. We just need a way to expose to applications that new feature are supported. Just like we did with zone capacity support. That is why we added the feature flags to uapi zone structure. > Think of a file system, or any other in-kernel user. If they have to change > their code based on the device type (NVMe vs SCSI), then the zoned block device > interface is broken. Right now, that is not the case, everything works equally > well on ZNS and SCSI, modulo the need by a user for conventional zones that ZNS > do not define. But that is still consistent with the host-managed model since > conventional zones are optional. That is why we have the feature flag. That user should not know the underlying transport or spec. But it can reliably discover "this thing support zone capacity" or "this thing supports offline zones" or even nasty thing like "this zone can time out when open" which are much harder to deal with. > For this particular patch, there is currently no in-kernel user, and it is not > clear how this will be useful to applications. At least please clarify this. And The main user is the ioctl. And if you think about how offline zones are (suppose to) be used driving this from management tools in userspace actually totally make sense. Unlike for example open/close all which just don't make sense as primitives to start with.
