On 3/21/23 09:44, Ming Lei wrote: > On Mon, Mar 20, 2023 at 04:32:57PM -0700, Bart Van Assche wrote: >> On 3/20/23 16:28, Ming Lei wrote: >>> On Fri, Mar 17, 2023 at 04:45:46PM -0700, Bart Van Assche wrote: >>>> Thanks for having taken a look. This patch series is intended for >>>> REQ_OP_WRITE requests and not for REQ_OP_ZONE_APPEND requests. >>> >>> But you are talking about host-managed zoned device, and the write >>> should have to be zone append, right? >> >> Hi Ming, >> >> The use case I'm looking at is Android devices with UFS storage. UFS is >> based on SCSI and hence only REQ_OP_WRITE is supported natively. There is a >> REQ_OP_ZONE_APPEND emulation in drivers/scsi/sd_zbc.c but it restricts the >> queue depth to one. > > But is this UFS one host-managed zoned device? If yes, this "REQ_OP_WRITE" > still should have been handled as REQ_OP_ZONE_APPEND? Otherwise, I don't > think it is host-managed, and your patch isn't needed too. Ming, Both regular writes and zone append writes are supported by host managed devices. For ZNS, zone append write is natively supported as a different command. For SCSI & ATA (and UFS) devices, zone append write is emulated in the sd driver using the regular write command because the SCSI and ATA standards do not define a zone append write command. For BIO splitting, splitting a regular write is fine as the resulting fragments are sequential writes, so all fine. But zone append splitting is not allowed as the actual written sector is returned by the device (or the sd emulation) to the block layer through the bio iter sector. So if a zone append is split and its fragments reordered, we can end up with a the wrong written sector and mangled data when considering the original large bio that was split. > > > Thanks, > Ming > -- Damien Le Moal Western Digital Research
