From: Damien Le Moal <dlemoal@kernel.org>
To: Bart Van Assche <bvanassche@acm.org>,
Hannes Reinecke <hare@suse.de>, Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
"Martin K . Petersen" <martin.petersen@oracle.com>,
Christoph Hellwig <hch@lst.de>, Ming Lei <ming.lei@redhat.com>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
Jaegeuk Kim <jaegeuk@kernel.org>
Subject: Re: [PATCH v11 04/16] scsi: core: Introduce a mechanism for reordering requests in the error handler
Date: Fri, 25 Aug 2023 08:53:02 +0900 [thread overview]
Message-ID: <5b94bd2d-78a0-b94b-621c-1732e2cce58c@kernel.org> (raw)
In-Reply-To: <1e54cf7a-4e8f-4539-6677-d6bf0ec88ea5@acm.org>
On 8/25/23 01:52, Bart Van Assche wrote:
> On 8/24/23 09:44, Hannes Reinecke wrote:
>> On 8/24/23 16:47, Bart Van Assche wrote:
>>> 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
>>> write 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.
>>
>> Yes. But the important thing to remember is that with 'zone append' the
>> resulting LBA will be returned on completion, they will _not_ be
>> specified in the submission. So any command reordering doesn't affect
>> the zone append commands as they heven't been written yet.
>>
>>> * 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.
>>>
>> Again, reordering is not an issue with zone append. With zone append you
>> specify in which zone the command should land, and upon completion the
>> LBA where the data is written will be returned.
>>
>> So if there is an error the command has not been written, consequently
>> there is no LBA to worry about, and you can reorder at will.
>
> Hi Hannes,
>
> I agree that reordering is not an issue for NVMe zone append commands.
> It is an issue however with SCSI devices because there is no zone append
> command in the SCSI command set. The sd_zbc.c code translates zone
> appends (REQ_OP_ZONE_APPEND) into regular WRITE commands. If these WRITE
> commands are reordered, the ZBC standard requires that these commands
> fail with an UNALIGNED WRITE error. So I think for SCSI devices what you
> wrote is wrong.
I think that Hannes point was that if you ensure that the rejected regular write
commands used to emulate zone append when requeued go through the sd driver
again when resubmitted, they will be changed again to emulate the original zone
append using the latest wp location, which is assumed correct. And that does not
depend on the ordering. So requeuing these regular writes does not need sorting.
It can be in any order. The constraint is of course that they must be re-preped
from the original REQ_OP_ZONE_APPEND every time they are requeued.
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2023-08-24 23:53 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-22 19:16 [PATCH v11 00/16] Improve write performance for zoned UFS devices Bart Van Assche
2023-08-22 19:16 ` [PATCH v11 01/16] block: Introduce more member variables related to zone write locking Bart Van Assche
2023-08-23 6:18 ` Hannes Reinecke
2023-08-23 8:08 ` Nitesh Shetty
2023-08-22 19:16 ` [PATCH v11 02/16] block: Only use write locking if necessary Bart Van Assche
2023-08-23 6:19 ` Hannes Reinecke
2023-08-23 8:09 ` Nitesh Shetty
2023-08-22 19:16 ` [PATCH v11 03/16] block/mq-deadline: Only use zone " Bart Van Assche
2023-08-23 6:21 ` Hannes Reinecke
2023-08-23 8:23 ` Nitesh Shetty
2023-08-22 19:16 ` [PATCH v11 04/16] scsi: core: Introduce a mechanism for reordering requests in the error handler Bart Van Assche
2023-08-23 6:26 ` Hannes Reinecke
2023-08-23 15:15 ` Bart Van Assche
2023-08-23 23:22 ` Damien Le Moal
2023-08-24 14:47 ` Bart Van Assche
2023-08-24 16:44 ` Hannes Reinecke
2023-08-24 16:52 ` Bart Van Assche
2023-08-24 23:53 ` Damien Le Moal [this message]
2023-08-25 1:00 ` Bart Van Assche
2023-08-22 19:17 ` [PATCH v11 05/16] scsi: core: Add unit tests for scsi_call_prepare_resubmit() Bart Van Assche
2023-08-22 19:17 ` [PATCH v11 06/16] scsi: sd: Sort commands by LBA before resubmitting Bart Van Assche
2023-08-22 19:17 ` [PATCH v11 07/16] scsi: core: Retry unaligned zoned writes Bart Van Assche
2023-08-22 19:17 ` [PATCH v11 08/16] scsi: sd_zbc: Only require an I/O scheduler if needed Bart Van Assche
2023-08-22 19:17 ` [PATCH v11 09/16] scsi: scsi_debug: Add the preserves_write_order module parameter Bart Van Assche
2023-08-22 19:17 ` [PATCH v11 10/16] scsi: scsi_debug: Support injecting unaligned write errors Bart Van Assche
2023-08-22 19:17 ` [PATCH v11 11/16] scsi: ufs: hisi: Rework the code that disables auto-hibernation Bart Van Assche
2023-08-22 19:17 ` [PATCH v11 12/16] scsi: ufs: Rename ufshcd_auto_hibern8_enable() and make it static Bart Van Assche
2023-08-22 19:17 ` [PATCH v11 13/16] scsi: ufs: Change the return type of ufshcd_auto_hibern8_update() Bart Van Assche
2023-08-22 19:17 ` [PATCH v11 14/16] scsi: ufs: Simplify ufshcd_auto_hibern8_update() Bart Van Assche
2023-08-22 19:17 ` [PATCH v11 15/16] scsi: ufs: Forbid auto-hibernation without I/O scheduler Bart Van Assche
2023-08-22 19:17 ` [PATCH v11 16/16] scsi: ufs: Inform the block layer about write ordering Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5b94bd2d-78a0-b94b-621c-1732e2cce58c@kernel.org \
--to=dlemoal@kernel.org \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=jaegeuk@kernel.org \
--cc=jejb@linux.ibm.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox