HSMR HDDs are a type of SMR HDD that allow for a dynamic mixture of CMR and SMR zones, allowing users to convert regions of the disk between the two. The way this is implemented as specified by the SCSI ZAC-2 specification is there’s a set of “CMR” regions and “SMR” regions. These may be grouped into “realms” that may, as a group, be online or offline. Zone management can bring online a domain/zone and offline any corresponding domains/zones. I’d like to discuss what path makes sense for supporting these devices, and also how to avoid potential issues specific to the “mixed CMR & SMR IO traffic” use case - particularly around latency due to potentially unneeded (from the perspective of an application) zone management commands. Points of Discussion ==== - There’s already support in the kernel for marking zones online/offline and cmr/smr, but this is fixed, not dynamic. Would there be hiccups with allowing zones to come online/offline while running? - There may be multiple CMR “zones” that are contiguous in LBA space. A benefit of HSMR disks is, to a certain extent, software which is designed for all-CMR disks can work similarly on a contiguous CMR area of the HSMR disk (modulo handling “resizes”). This may result in IO that can straddle two CMR “zones”. It’s not a problem for writes to span CMR zones, but it is for SMR zones, so this distinction is useful to have in the block layer. - What makes sense as an interface for managing these types of not-quite CMR and not quite SMR disks? Some of the featureset overlaps with existing SMR support in blkdev_zone_mgmt_ioctl, so perhaps the additional conversion commands could be added there? - mitigating & limiting tail latency effects due to report zones commands / limiting “unnecessary” zone management calls. Thanks, Khazhy
