>> >> 1) why is a partial mapping of the underlying device disallowed? >> 2) why is it assumed all IO is read-only? (talk to me and others like >> we don't know the inherent limitations of this class of zoned hw) >> >> On a code level: >> 1) are you certain you're properly failing all writes? >> - are writes allowed to the "zone capacity area" but _not_ >> allowed to the "emulated zone area"? (if yes, _please document_). >> 2) yes, you absolutely need to implement the .status target_type hook >> (for both STATUS and TABLE). >> 3) really not loving the nested return (of DM_MAPIO_SUBMITTED or >> DM_MAPIO_REMAPPED) from methods called from dm_po2z_map(). Would >> prefer to not have to do a depth-first search to see where and when >> dm_po2z_map() returns a DM_MAPIO_XXX unless there is a solid >> justification for it. To me it just obfuscates the DM interface a >> bit too much. >> >> Otherwise, pretty clean code and nothing weird going on. >> >> I look forward to seeing your next (final?) revision of this patchset. > > Thinking further.. I'm left confused about just what the heck this > target is assuming. > > E.g.: feels like its exposing a readonly end of the zone is very > bi-polar... yet no hint to upper layer it shouldn't write to that > read-only end (the "emulated zone").. but there has to be some zoned > magic assumed? And I'm just naive? > You are absolutely right about "zoned magic". Applications that use a zoned block device are aware of the zone capacity and zone size. BLKREPORTZONE ioctl is typically used to get the zone information from a zoned block device. This target adjusts the zone report so that zone size and zone capacity are modified correctly (see dm_po2z_report_zones() and dm_po2z_report_zones_cb() functions). -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
