From: Bart Van Assche <bvanassche@acm.org>
To: Roman Bolshakov <r.bolshakov@yadro.com>
Cc: Anastasia Kovaleva <a.kovaleva@yadro.com>,
target-devel@vger.kernel.org, linux-scsi@vger.kernel.org,
linux@yadro.com
Subject: Re: [PATCH 3/3] scsi: target: core: Change ASCQ for residual write
Date: Sun, 25 Oct 2020 00:25:17 +0000 [thread overview]
Message-ID: <b831a7db-1da2-c293-a8f6-d9c62f68c224@acm.org> (raw)
In-Reply-To: <20201024121315.GA35317@SPB-NB-133.local>
On 10/24/20 5:13 AM, Roman Bolshakov wrote:
> iSCSI doesn't specify a specific code but mentions a possibility of CHECK
> CONDITION for residuals (11.4.5.1. Field Semantics):
>
> Targets may set the residual count, and initiators may use it when the
> response code is Command Completed at Target (even if the status
> returned is not GOOD).
My interpretation of the above text is that it neither allows nor
requires to change the status GOOD into something else if there is a
residue.
>> Additionally, what benefits does it provide to report a CHECK CONDITION
>> upon residual overflow?
>
> Typical use case for CHECK CONDITION in case of Underflow/Overflow is
> extra robustness against buggy initiators [1][2]. Failing both READ and
> WRITE is the most solid approach in that sense [3][4][5] as it prevents
> data corruption at all costs.
>
> Suppose an initiator wants to WRITE 8 LBA. For 512-byte formatted LUN,
> 8 LBAs need a buffer of 4K bytes. For 4096-byte formatted LUN the
> command would need 32K data buffer.
>
> An Overflow happens if initiator treats 4Kn device like 512n one but
> provides a buffer of 4K. i.e. to complete the WRITE target needs to
> consume 28K more data, otherwise only 1 LBA would be written and the
> rest 7 LBAs would have indeterminate content.
>
> An Underflow happens if initiator confuses 512n device with 4Kn one and
> provides a buffer of 32K, i.e. target doesn't utilize all buffer for the
> command.
Thanks for the additional background information, this really helps. How
about only rejecting SCSI commands for which the data buffer size is not
a multiple of the block size? I'm concerned that flagging all SCSI
commands that have a residue as invalid will break SCSI tape software.
Thanks,
Bart.
next prev parent reply other threads:[~2020-10-25 0:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-22 17:20 [PATCH 0/3] scsi: target: Set correct residual data Anastasia Kovaleva
2020-10-22 17:20 ` [PATCH 1/3] scsi: target: core: Set residuals for 4Kn devices Anastasia Kovaleva
2020-10-22 17:20 ` [PATCH 2/3] scsi: target: core: Signal WRITE residuals Anastasia Kovaleva
2020-10-22 17:20 ` [PATCH 3/3] scsi: target: core: Change ASCQ for residual write Anastasia Kovaleva
2020-10-24 4:07 ` Bart Van Assche
2020-10-24 12:13 ` Roman Bolshakov
2020-10-25 0:25 ` Bart Van Assche [this message]
2020-10-26 13:12 ` Roman Bolshakov
2020-10-27 2:42 ` Bart Van Assche
2020-10-27 23:46 ` Roman Bolshakov
2020-10-28 3:41 ` Bart Van Assche
2020-11-10 16:57 ` Anastasia Kovaleva
2020-11-15 3:17 ` Bart Van Assche
2020-10-26 17:33 ` Bodo Stroesser
2020-10-24 3:54 ` [PATCH 0/3] scsi: target: Set correct residual data 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=b831a7db-1da2-c293-a8f6-d9c62f68c224@acm.org \
--to=bvanassche@acm.org \
--cc=a.kovaleva@yadro.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linux@yadro.com \
--cc=r.bolshakov@yadro.com \
--cc=target-devel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).