Re: [Ips] Data Out residual overflow/underflow handling

Paul Hughes <phughes@solidfire.com> Fri, 21 September 2012 15:45 UTC

Return-Path: <phughes@solidfire.com>
X-Original-To: ips@ietfa.amsl.com
Delivered-To: ips@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599D521E8040 for <ips@ietfa.amsl.com>; Fri, 21 Sep 2012 08:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxFMK9wWXjcA for <ips@ietfa.amsl.com>; Fri, 21 Sep 2012 08:45:17 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F380321E803D for <ips@ietf.org>; Fri, 21 Sep 2012 08:45:16 -0700 (PDT)
Received: by vbbfc26 with SMTP id fc26so4367145vbb.31 for <ips@ietf.org>; Fri, 21 Sep 2012 08:45:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=TELgdrY/DnuEgz8KKaoOzLPC/xIMPanM0T8E8xZqLzU=; b=F64ehyACvi9hF0GoJ7gPSCX8TXhQuNZjb5cY0wXRwMp+HQD6n34nsPHKoViECMvjaJ 5Ow6tZBVFuRNFI481wWfq4DQ1Qgc1QMwVjpdew9lcKnJ4OaoSlnvO7hupkuSoomCSwsq 1nv5RQMyKoPclRU/OcCAEwE+GA8P32rKsFP2Sm+JXA054VUUNIoG2w6EmftWSbhGQjv/ Q16WANeRqMv5S06LRHKaUc8Z/hSM0Vw8Z+d67jMglDptP8C1siRp/Vlm4ukvv8Gx7y7y wuxIZ7CpE+A9AHFXrhS6u7sVceMUal/0gs8s5bYWqMlNbb777LqLRfw68oOAut9QSWQy rYRA==
MIME-Version: 1.0
Received: by 10.52.37.229 with SMTP id b5mr2592797vdk.70.1348242316194; Fri, 21 Sep 2012 08:45:16 -0700 (PDT)
Received: by 10.58.18.174 with HTTP; Fri, 21 Sep 2012 08:45:16 -0700 (PDT)
In-Reply-To: <FFEE311F0EC80C4EA64EC8757CAD0CD208EA1E32@SACEXCMBX04-PRD.hq.netapp.com>
References: <CAGBQytv=iMoqW372kYs1Ltf=Wd4GVdCytOa2hJdEX7Nu9JTT_g@mail.gmail.com> <FFEE311F0EC80C4EA64EC8757CAD0CD208EA1E32@SACEXCMBX04-PRD.hq.netapp.com>
Date: Fri, 21 Sep 2012 09:45:16 -0600
Message-ID: <CAGBQytuQdSdUxgaMBPgaUp2mC1aJDy1y6ePy4JAmbJWDe7TDZQ@mail.gmail.com>
From: Paul Hughes <phughes@solidfire.com>
To: "Knight, Frederick" <Frederick.Knight@netapp.com>
Content-Type: multipart/alternative; boundary=bcaec51d2e4453f30b04ca382056
X-Gm-Message-State: ALoCoQkGmIh9WE8AH/kSGPbj9L83YwsYZAytC0w/G8B8a0B6x5gLY7gkQtK5WIw+Elujsud6Q/xl
Cc: "ips@ietf.org" <ips@ietf.org>
Subject: Re: [Ips] Data Out residual overflow/underflow handling
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ips>, <mailto:ips-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ips>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Sep 2012 15:45:18 -0000

Thanks for the detailed response Fred.  I will post this question to the
T10 reflector to see what they have to say, but thought I'd start here.

One follow up question:  If the initiator didn't send any immediate data
(the iSCSI Command Request PDU EDTL=512, but the data segment length is 0
and the Final bit is set), would the target have the same options?  I
believe the only difference would be the Sense Key that is reported
(Illegal Request if no immediate data was transferred, and Aborted Command
if immediate data was transferred).  I expect the residual reporting would
remain the same regardless of whether any data was transferred or not,
correct?

Thanks,
Paul



On Fri, Sep 21, 2012 at 8:00 AM, Knight, Frederick <
Frederick.Knight@netapp.com>; wrote:

>  You have a couple of choices.****
>
> ** **
>
> For example, SBC makes several statements about non-deterministic outcomes
> such as:****
>
> ** **
>
> The device server may terminate the command before processing or after the
> device server has transferred some or all of the data. (walking off the
> end of the device)****
>
> ** **
>
> The degree that the medium is altered by this command is vendor specific.(The format command)
> ****
>
> ** **
>
> But those aren’t directly related.  However, as you mention, FCP provides
> the following 3 choice:****
>
> If the command requested that data beyond the length specified by the FCP_DL
> field be transferred, then the device server shall set the FCP_RESID_OVER bit
> (see 9.5.8) to one in the FCP_RSP IU and:****
>
> **a)       **process the command normally except that data beyond the FCP_DL
> count shall not be requested or transferred;****
>
> **b)       **transfer no data and return CHECK CONDITION status with the
> sense key set to ILLEGAL REQUEST and the additional sense code set to
> INVALID FIELD IN COMMAND INFORMATION UNIT; or****
>
> **c)           **may transfer data and return CHECK CONDITION status with
> the sense key set to ABORTED COMMAND and the additional sense code set to
> INVALID FIELD IN COMMAND INFORMATION UNIT.****
>
> ** **
>
> Case a) and c) allow the media to be modified.  Case b) implies no media
> alteration (since no data is transferred).  Choice b) and c) include SCSI
> layer sense data, but choice a) includes only an FCP layer notification (no
> SCSI sense data, so a broken host (one that ignores residual unless a check
> condition exists) will assume success).****
>
> ** **
>
> RFC5048 says:****
>
>    If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the****
>
>    SCSI Response PDU as specified in [RFC3720].  The Residual Count MUST**
> **
>
>    be set to the numerical value of (SPDTL - EDTL).****
>
> ** **
>
> SPDTL = the SCSI layer transfer size; EDTL = the iSCSI layer transfer size.
> ****
>
> ** **
>
> Since the SCSI layer transfer size in your example is 4096, and the iSCSI
> layer transfer size is 512, then you must report the OVERFLOW as defined in
> RFC3720 (bit 5 in the flags field of the SCSI response PDU).  I couldn’t
> quickly find any suggestions in RFC3720/5048 for sense data, so I’d suggest
> you go with choice b) or c) that FCP is using (I’d suggest staying away
> from choice a) since it has bad possibilities).  At least that is
> something hosts should already be familiar with.****
>
> ** **
>
> The other list you might use for these kinds of questions is the SCSI
> reflector: t10@t10.org (T10 defines the SCSI architecture and writes the
> various SCSI command standards).****
>
> ** **
>
>                 Fred Knight****
>
> ** **
>
> ** **
>
> *From:* ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] *On Behalf Of *Paul
> Hughes
> *Sent:* Thursday, September 20, 2012 11:22 PM
> *To:* ips@ietf.org
> *Subject:* [Ips] Data Out residual overflow/underflow handling****
>
> ** **
>
> Not sure if this is the best place to ask, but here goes...****
>
> ** **
>
> How should an iSCSI target (SCSI direct-access block device) handle the
> following scenario:****
>
> ** **
>
> An initiator issues an iSCSI Command Request PDU containing a SCSI Write
> CDB with a transfer length of 1 block.  The iSCSI Command Request PDU has
> an Expected Data Transfer Length of 512 bytes, a Data Segment Length of 512
> bytes (immediate data), and the Final flag is set.  This would be a
> perfectly normal single block write, except that the target's logical unit
> is formatted with 4096-byte block size.  So it appears the initiator is
> confused and sending a single 512-byte block write to a logical unit that
> is formatted to 4KB block size.****
>
> ** **
>
> Here are my thoughts:****
>
> ** **
>
> 1) The target could write the 512 bytes of immediate data plus 3584 bytes
> (4096 minus 512) of whatever it wants to the media, and then send an iSCSI
> Command Response PDU with SCSI status of Good and reporting an Overflow
> with a residual count of 3584.  This seems to be the most correct way of
> handling this scenario, but it seems dangerous to allow an apparently
> confused initiator to essentially corrupt data on the logical unit.****
>
> ** **
>
> 2) The target could send an iSCSI Command Response PDU with SCSI status of
> Check Condition, with sense data of Aborted Command, Invalid Field in
> Command Information Unit (0x0E03).  This sense code is apparently intended
> for FCP (I found it mentioned in FCP-4) but it seems appropriate in this
> case.  Assuming the target can fail the SCSI Write command this way (or
> some other way), should the target also report an Underflow with a residual
> count of 512?****
>
> ** **
>
> Are there any other alternatives?****
>
> ** **
>
> Thanks,****
>
> Paul****
>
> ** **
>
> ** **
>
> ** **
>