On 2021/04/19 21:52, Mikulas Patocka wrote: > > > On Sat, 17 Apr 2021, Damien Le Moal wrote: > >> Mike, >> >> Zone append BIOs (REQ_OP_ZONE_APPEND) always specify the start sector >> of the zone to be written instead of the actual location sector to >> write. The write location is determined by the device and returned to >> the host upon completion of the operation. > > I'd like to ask what's the reason for this semantics? Why can't users of > the zoned device supply real sector numbers? They can, if they use regular write commands :) Zone append was designed to address sequential write ordering difficulties on the host. Unlike regular writes which must be delivered to the device in sequential order, zone append commands can be sent to the device in any order. The device will process the write at the WP position when the command is executed and return the first sector written. This command makes it easy on the host in multi-queue environment and avoids the need for serializing commands & locking zones for writing. So very efficient performance. >> This interface, while simple and efficient for writing into sequential >> zones of a zoned block device, is incompatible with the use of sector >> values to calculate a cypher block IV. All data written in a zone is >> encrypted using an IV calculated from the first sectors of the zone, >> but read operation will specify any sector within the zone, resulting >> in an IV mismatch between encryption and decryption. Reads fail in that >> case. > > I would say that it is incompatible with all dm targets - even the linear > target is changing the sector number and so it may redirect the write > outside of the range specified in dm-table and cause corruption. DM remapping of BIO sectors is zone compatible because target entries must be zone aligned. In the case of zone append, the BIO sector always point to the start sector of the target zone. DM sector remapping will remap that to another zone start as all zones are the same size. No issue here. We extensively use dm-linear for various test environment to reduce the size of the device tested (to speed up tests). I am confident there are no problems there. > Instead of complicating device mapper with imperfect support, I would just > disable REQ_OP_ZONE_APPEND on device mapper at all. That was my initial approach, but for dm-crypt only since other targets that support zoned devices are fine. However, this breaks zoned block device requirement that zone append be supported so that users are presented with a uniform interface for different devices. So while simple to do, disabling zone append is far from ideal. > > Mikulas > > -- Damien Le Moal Western Digital Research