On 6/14/22 14:47, Khazhy Kumykov wrote:
On Tue, Jun 14, 2022 at 10:49 AM Bart Van Assche <bvanassche@xxxxxxx> wrote:
From ZBC-2: "The device server terminates with CHECK CONDITION status, with
the sense key set to ILLEGAL REQUEST, and the additional sense code set to
UNALIGNED WRITE COMMAND a write command, other than an entire medium write
same command, that specifies: a) the starting LBA in a sequential write
required zone set to a value that is not equal to the write pointer for that
sequential write required zone; or b) an ending LBA that is not equal to the
last logical block within a physical block (see SBC-5)."
I am not aware of any other conditions that may trigger the UNALIGNED
WRITE COMMAND response.
Retry unaligned writes in preparation of removing zone locking.
Is /just/ retrying effective here? A series of writes to the same zone
would all need to be sent in order - in the worst case (requests
somehow ordered in reverse order) this becomes quadratic as only 1
request "succeeds" out of the N outstanding requests, with the rest
all needing to retry. (Imagine a user writes an entire "zone" - which
could be split into hundreds of requests).
Block layer / schedulers are free to do this reordering, which I
understand does happen whenever we need to requeue - and would result
in a retry of all writes after the first re-ordered request. (side
note: fwiw "requests somehow in reverse order" can happen - bfq
inherited cfq's odd behavior of sometimes issuing sequential IO in
reverse order due to back_seek, e.g.)
Hi Khazhy,
For zoned block devices I propose to only support those I/O schedulers
that either preserve the LBA order or fix the LBA order if two or more
out-of-order requests are received by the I/O scheduler.
I agree that in the worst case the number of retries is proportional to
the square of the number of pending requests. However, for the use case
that matters most to me, F2FS on top of a UFS device, we haven't seen
any retries in our tests without I/O scheduler. This is probably because
of how F2FS submits writes combined with the UFS controller only
supporting a single hardware queue. I expect to see a small number of
retries once UFS controllers become available that support multiple
hardware queues.
Thanks,
Bart.
