> Sounds like you voluntered to teach zoned storage use 101. Can you teach me > how to calculate an LBA offset given a zone number when zone capacity is not > equal to zone size? zonesize_pow = x; // e.g., x = 32 if 2GiB Zone size /w 512B block size zone_id = y; // valid zone id struct blk_zone zone = zones[zone_id]; // zones is a linear array of blk_zone structs that holds per zone information. With that, one can do the following 1a) first_lba_of_zone = zone_id << zonesize_pow; 1b) first_lba_of_zone = zone.start; 2a) next_writeable_lba = (zoneid << zonesize_pow) + zone.wp; 2b) next_writeable_lba = zone.start + zone.wp; 3) writeable_lbas_left = zone.len - zone.wp; 4) lbas_written = zone.wp - 1; > The second thing I would like to know is what happens when an application > wants to map an object that spans multiple consecutive zones. Does the > application have to be aware of the difference in zone capacity and zone size? The zoned namespace command set specification does not allow variable zone size. The zone size is fixed for all zones in a namespace. Only the zone capacity has the capability to be variable. Usually, the zone capacity is fixed, I have not yet seen implementations that have variable zone capacities. An application that wants to place a single object across a set of zones would have to be explicitly handled by the application. E.g., as well as the application, should be aware of a zone's capacity, it should also be aware that it should reset the set of zones and not a single zone. I.e., the application must always be aware of the zones it uses. However, an end-user application should not (in my opinion) have to deal with this. It should use helper functions from a library that provides the appropriate abstraction to the application, such that the applications don't have to care about either specific zone capacity/size, or multiple resets. This is similar to how file systems work with file system semantics. For example, a file can span multiple extents on disk, but all an application sees is the file semantics.
