On 26.06.2020 11:17, hch@xxxxxx wrote:
On Fri, Jun 26, 2020 at 09:15:14AM +0000, Damien Le Moal wrote:
On 2020/06/26 18:11, hch@xxxxxx wrote:
> 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.
OK. Adding a new BLKZONEOFFLINE ioctl is easy though and fits into the current
zone management plumbing well, I think. So the patch can be significantly
simplified (no need for the new zone management op function with flags).
Yes, I'm all for reusing the existing plumbing and style as much as
possible.
OK. Will use the current path on V2.
Thanks!
Javier
