On 8/23/23 16:22, Damien Le Moal wrote:
The sd driver does have zone append emulation using regular writes. The emulation relies on zone write locking to avoid issues with adapters that do not have strong ordering guarantees, but that could be adapted to be removed for UFS devices with write ordering guarantees. This solution would greatly simplify your series since zone append requests are not subject to zone write locking at the block layer. So no changes would be needed at that layer. However, that implies that your preferred use case (f2fs) must be adapted to use zone append instead of regular writes. That in itself may be a bigger-ish change, but in the long run, likely a better one I think as that would be compatible with NVMe ZNS and also future UFS standards defining a zone append command.
Hi Damien, Thanks for the feedback. I agree that it would be great to have zone append support in F2FS. However, I do not agree that switching from regular writes to zone append in F2FS would remove the need for sorting SCSI commands by LBA in the SCSI error handler. Even if F2FS would submit zoned writes then the following mechanisms could still cause reordering of the zoned writes after these have been translated into regular writes: * The SCSI protocol allows SCSI devices, including UFS devices, to respond with a unit attention or the SCSI BUSY status at any time. If multiple write commands are pending and some of the pending SCSI writes are not executed because of a unit attention or because of another reason, this causes command reordering. * Although the link between the UFS controller and the UFS device is pretty reliable, there is a non-zero chance that a SCSI command is lost. If this happens the SCSI timeout and error handlers are activated. This can cause reordering of write commands. In other words, whether F2FS submits regular writes (REQ_OP_WRITE) or zone appends (REQ_OP_ZONE_APPEND), I think we need the entire patch series. Thanks, Bart.
