On 3/23/23 15:53, Damien Le Moal wrote:
On 3/24/23 01:27, Bart Van Assche wrote:
On 3/23/23 03:28, Damien Le Moal wrote:
For the zone append emulation, the write locking is done by sd.c and the upper
layer does not restrict to one append per zone. So we actually could envision a
UFS version of the sd write locking calls that is optimized for the device
capabilities and we can keep a common upper layer (which is preferable in my
opinion).
I see a blk_req_zone_write_trylock() call in
sd_zbc_prepare_zone_append() and a blk_req_zone_write_unlock() call in
sd_zbc_complete() for REQ_OP_ZONE_APPEND operations. Does this mean that
the sd_zbc.c code restricts the queue depth to one per zone for
REQ_OP_ZONE_APPEND operations?
Yes, since the append becomes a regular write and HBAs are often happy to
reorder these commands, even for SMR, we need the locking.
But if I understand your use case correctly, given that UFS gives guarantees on
the command dispatching order, you could probably relax this locking for zone
append requests. But you cannot for regular writes as the locking is up in the
block layer and needed to avoid block layer level reordering.
Hi Damien,
I don't think that we can achieve QD > 1 even if we would switch to
REQ_OP_ZONE_APPEND. A SCSI LLD is allowed to respond with
SCSI_MLQUEUE_HOST_BUSY if the SCSI core asks it to queue a command. This
may lead to reordering and hence may cause UNALIGNED WRITE COMMAND
errors. We want to avoid these errors.
Thanks,
Bart.
