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.
