target-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roman Bolshakov <r.bolshakov@yadro.com>
To: Bart Van Assche <bvanassche@acm.org>
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: Tue, 27 Oct 2020 23:46:39 +0000	[thread overview]
Message-ID: <20201027234639.GB88490@SPB-NB-133.local> (raw)
In-Reply-To: <270e2edf-49c9-942f-ac3d-b6dfa0aca8f7@acm.org>

On Mon, Oct 26, 2020 at 07:42:55PM -0700, Bart Van Assche wrote:
> On 10/26/20 6:12 AM, Roman Bolshakov wrote:
> > Note, that if we talk about SSC over FCP, then "9.4.2 FCP_DATA IUs for
> > read and write operations" does additionally apply. Perhaps a) from
> > "9.4.2 FCP_DATA IUs for read and write operations" works well for SSC:
> > 
> >   a) process the command normally except that data beyond the FCP_DL count
> >   shall not be requested or transferred;
> > 
> > The clause allows to accomodate variable-block tranfers from SSC.
> > 
> > So, what if we return CHECK CONDITION only for SBC WRITEs with
> > residuals?  Then it has no impact on SSC and other device types. In
> > future, we might also add a patch that would fail SBC READs with
> > residuals for sake of consistency. That behaviour would be beneficial
> > for SBC devices as no host could corrupt data or itself by forming,
> > requesting invalid data buffer.
> 
> Maybe I'm overly concerned. I do not know for sure which applications
> rely on the current behavior of residual handling. All I know about
> these applications is based on what others wrote about these
> applications. An example from
> https://www.t10.org/pipermail/t10/2003-November/009317.html: "We have
> customers who also use overlength and underlength transfers as a normal
> mode of operation."
> 

Hi Bart,

Thanks for raising the point about overlength/underlength. If you wish
we can add an extra check that fails DMA_TO_DEVICE && DATA with
residuals only for SBC devices but note that before the series,
underflow/overflow for WRITE didn't return GOOD status. The particular
patch only changes sense code to more meaningful from the former INVALID
FIELD IN CDB.

Theoretically, it could be good to have a configurable switch how LIO
handles overflows/underflows for a LUN. Then it'd be possible to
configure desired behaviour on a per-LUN basis. But there should be a
clear need & demand for the feature to avoid maintenance of dead code.

> An additional question is what behavior other operating systems than
> Linux expect? There are probably setups in which another operating
> system than Linux communicates with a LIO SCSI target?
> 

TBH I don't know any hosts that do SBC WRITE with residuals as normal
course of operation. They wouldn't be able to work with LIO because it
never returns GOOD status on WRITE with residuals. I can send an update
later if the series works fine with modern hosts (~1 month, after a few
cycles of system testing).

Fun fact, ~60 years ago WRITE overflows were used to achieve behaviour
similar to disk zeroing/WRITE SAME [1].

1. https://mailarchive.ietf.org/arch/msg/ips/135ycRlgwUg1sb3gRrUQ3-lSXg0/

Thanks,
Roman

  reply	other threads:[~2020-10-27 23:46 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
2020-10-26 13:12         ` Roman Bolshakov
2020-10-27  2:42           ` Bart Van Assche
2020-10-27 23:46             ` Roman Bolshakov [this message]
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=20201027234639.GB88490@SPB-NB-133.local \
    --to=r.bolshakov@yadro.com \
    --cc=a.kovaleva@yadro.com \
    --cc=bvanassche@acm.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux@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).