target-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).