From phughes@solidfire.com Thu Sep 20 20:21:33 2012 Return-Path: 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 ADD0621E80A6 for ; Thu, 20 Sep 2012 20:21:33 -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 EMS84wE0j17a for ; Thu, 20 Sep 2012 20:21:33 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1BDB21E809E for ; Thu, 20 Sep 2012 20:21:32 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so3653866vcb.31 for ; Thu, 20 Sep 2012 20:21:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=tftAUKMqADu8Uu0ubnQJ5wkp6kxmyje2KDcVbpSVKQA=; b=ZNKwNgGHQBoeCRsdnlJQVFaBSecB8T0kOGzertpfCvC3xJ1heBQ+MFSZmYT3cOk44X m8DMQsbgWPnwCFiIpc0sBL6PJKsAw+PdUWkESQZd6e7MOPhu/N7nyjg0w4OGMTzbGbtA 9x9itKSMGOQ0CgKCHqLCptMZznJ545VbTwCzJ4Ev5Zs+vVfoVJiFh2il18T/jM97ZVSr NyA69dTRUtQExDODZviwtxj9GqIj3svMWRNcq5tUOjGBzr8XSqlha4osYAiH8NRQLyPn vtpXyl5OS57dWybXC0bHpFMboav0AMwMzEl+zbOscd+o9agCy2/QqrT7UwHwf8Z3LAGj Y4Nw== MIME-Version: 1.0 Received: by 10.220.116.9 with SMTP id k9mr2253667vcq.0.1348197692186; Thu, 20 Sep 2012 20:21:32 -0700 (PDT) Received: by 10.58.18.174 with HTTP; Thu, 20 Sep 2012 20:21:32 -0700 (PDT) Date: Thu, 20 Sep 2012 21:21:32 -0600 Message-ID: From: Paul Hughes To: ips@ietf.org Content-Type: multipart/alternative; boundary=f46d043894a9879eae04ca2dbc33 X-Gm-Message-State: ALoCoQkriR3MPLO/CYzZiFmqCMdDOYfz648QisM3SfN9Vf9hZV0PmvGzLRHoj5Ahch1tPEt1C1Sw Subject: [Ips] Data Out residual overflow/underflow handling X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 03:21:33 -0000 --f46d043894a9879eae04ca2dbc33 Content-Type: text/plain; charset=ISO-8859-1 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 --f46d043894a9879eae04ca2dbc33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not sure if this is the best place to ask, but here goes...

<= div>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. =A0The iSCSI Command Request PDU has an Expected Data Transfer Leng= th of 512 bytes, a Data Segment Length of 512 bytes (immediate data), and t= he Final flag is set. =A0This would be a perfectly normal single block writ= e, except that the target's logical unit is formatted with 4096-byte bl= ock size. =A0So it appears the initiator is confused and sending a single 5= 12-byte block write to a logical unit that is formatted to 4KB block size.<= /div>

Here are my thoughts:

1) The t= arget could write the 512 bytes of immediate data plus 3584 bytes (4096 min= us 512) of whatever it wants to the media, and then send an iSCSI Command R= esponse PDU with SCSI status of Good and reporting an Overflow with a resid= ual count of 3584. =A0This seems to be the most correct way of handling thi= s scenario, but it seems dangerous to allow an apparently confused initiato= r to essentially corrupt data on the logical unit.

2) The target could send an iSCSI=A0Command Response PD= U with SCSI status of Check Condition, with sense data of Aborted Command, = Invalid Field in Command Information Unit (0x0E03). =A0This sense code is a= pparently intended for FCP (I found it mentioned in FCP-4) but it seems app= ropriate in this case. =A0Assuming the target can fail the SCSI Write comma= nd this way (or some other way), should the target also report an Underflow= with a residual count of 512?

Are there any other alternatives?

<= div>Thanks,
Paul



--f46d043894a9879eae04ca2dbc33-- From Frederick.Knight@netapp.com Fri Sep 21 07:00:27 2012 Return-Path: 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 87DF621F883E for ; Fri, 21 Sep 2012 07:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 O1MYTlNO3hH0 for ; Fri, 21 Sep 2012 07:00:24 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6B30421F883C for ; Fri, 21 Sep 2012 07:00:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,463,1344236400"; d="scan'208,217";a="692353614" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 21 Sep 2012 07:00:24 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q8LE0NoM011340; Fri, 21 Sep 2012 07:00:23 -0700 (PDT) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.102]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0309.002; Fri, 21 Sep 2012 07:00:22 -0700 From: "Knight, Frederick" To: Paul Hughes , "ips@ietf.org" Thread-Topic: [Ips] Data Out residual overflow/underflow handling Thread-Index: AQHNl6g2O+NxDnTbLUmdQtQdgB+XcJeUsD4Q Date: Fri, 21 Sep 2012 14:00:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/alternative; boundary="_000_FFEE311F0EC80C4EA64EC8757CAD0CD208EA1E32SACEXCMBX04PRDh_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:00:27 -0000 --_000_FFEE311F0EC80C4EA64EC8757CAD0CD208EA1E32SACEXCMBX04PRDh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 t= he following 3 choice: If the command requested that data beyond the length specified by the FCP_D= L 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 co= unt 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 FIE= LD IN COMMAND INFORMATION UNIT; or c) may transfer data and return CHECK CONDITION status with the s= ense key set to ABORTED COMMAND and the additional sense code set to INVALI= D FIELD IN COMMAND INFORMATION UNIT. Case a) and c) allow the media to be modified. Case b) implies no media al= teration (since no data is transferred). Choice b) and c) include SCSI lay= er sense data, but choice a) includes only an FCP layer notification (no SC= SI sense data, so a broken host (one that ignores residual unless a check c= ondition 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 =3D the SCSI layer transfer size; EDTL =3D the iSCSI layer transfer s= ize. Since the SCSI layer transfer size in your example is 4096, and the iSCSI l= ayer 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 qu= ickly find any suggestions in RFC3720/5048 for sense data, so I'd suggest y= ou 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 hos= ts should already be familiar with. The other list you might use for these kinds of questions is the SCSI refle= ctor: t10@t10.org (T10 defines the SCSI architecture an= d 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 fol= lowing scenario: An initiator issues an iSCSI Command Request PDU containing a SCSI Write CD= B 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 by= tes (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 format= ted 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 C= ommand 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 handli= ng this scenario, but it seems dangerous to allow an apparently confused in= itiator 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 Comma= nd Information Unit (0x0E03). This sense code is apparently intended for F= CP (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 --_000_FFEE311F0EC80C4EA64EC8757CAD0CD208EA1E32SACEXCMBX04PRDh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 processi= ng 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 ve= ndor specific. (The format command)

 

But those aren’t directly related.  However, as you mention, FCP provides the following 3 choice:=

If the command re= quested that data beyond the length specified by the FCP<= /span>_DL fie= ld 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<= /span>_DL cou= nt shall not be requested or transferred;

b)       transfer no data and return CHECK CONDITION status with the s= ense key set to ILLEGAL REQUEST and the additional sense code set to INVALI= D FIELD IN COMMAND INFORMATION UNIT; or

c)  &= nbsp;        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 COMM= AND INFORMATION UNIT.

 

Case a) and c) allow the media to be modified.  Case b) implies no media alteration (since no data is transferred).<= span style=3D"mso-spacerun:yes">  Choice b) and c) include SCSI layer sense data, but choice a) includ= es only an FCP layer notification (no SCSI sense data, so a broken host (on= e that ignores residual unless a check condition exists) will assume succes= s).

 

RFC5048 says:

   If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in th= e

   SCSI Response PDU as specified in [RFC3720].  The Residual Count MUST

   be set to the numerical value of (SPDTL= - EDTL).

 

SPDTL =3D the SCSI layer transfer size; EDTL =3D th= e 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 r= esponse PDU).  I couldn’t quickly find any suggestions in RFC3720/5048 for se= nse data, so I’d suggest you go with choice b) or c) that FCP is usin= g (I’d suggest staying away from choice a) since it has bad possibili= ties).  At least that is something hosts should already be familiar with.

 

The other list you might use for these kinds of que= stions is the SCSI reflector: t10@t10.org (T10 defines the SCSI archit= ecture and writes the various SCSI command standards).

 

   &= nbsp;            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 con= taining 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 D= ata Segment Length of 512 bytes (immediate data), and the Final flag is set.  This would be a perfectly normal s= ingle block write, except that the target's logical unit is formatted with = 4096-byte block size.  So it appears the initiator is confused and sen= ding 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, a= nd then send an iSCSI Command Response PDU with SCSI status of Good and rep= orting an Overflow with a residual count of 3584.  This seems to be the most correct way of handling thi= s scenario, but it seems dangerous to allow an apparently confused initiato= r to essentially corrupt data on the logical unit.

 

2) The target could send an iSCSI Command Respo= nse PDU with SCSI status of Check Condition, with sense data of Aborted Com= mand, 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.  Assumi= ng 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

 

 

 

--_000_FFEE311F0EC80C4EA64EC8757CAD0CD208EA1E32SACEXCMBX04PRDh_-- From phughes@solidfire.com Fri Sep 21 08:45:18 2012 Return-Path: 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 ; 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 ; 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 ; Fri, 21 Sep 2012 08:45:16 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so4367145vbb.31 for ; 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: References: Date: Fri, 21 Sep 2012 09:45:16 -0600 Message-ID: From: Paul Hughes To: "Knight, Frederick" Content-Type: multipart/alternative; boundary=bcaec51d2e4453f30b04ca382056 X-Gm-Message-State: ALoCoQkGmIh9WE8AH/kSGPbj9L83YwsYZAytC0w/G8B8a0B6x5gLY7gkQtK5WIw+Elujsud6Q/xl Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:45:18 -0000 --bcaec51d2e4453f30b04ca382056 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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=3D512, 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 outcome= s > such as:**** > > ** ** > > The device server may terminate the command before processing or after th= e > 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=92t directly related. However, as you mention, FCP provid= es > 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 che= ck > 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 =3D the SCSI layer transfer size; EDTL =3D 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=92= t > quickly find any suggestions in RFC3720/5048 for sense data, so I=92d sug= gest > you go with choice b) or c) that FCP is using (I=92d 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 5= 12 > bytes (immediate data), and the Final flag is set. This would be a > perfectly normal single block write, except that the target's logical uni= t > 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 iSCS= I > 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 o= f > Check Condition, with sense data of Aborted Command, Invalid Field in > Command Information Unit (0x0E03). This sense code is apparently intende= d > 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 residu= al > count of 512?**** > > ** ** > > Are there any other alternatives?**** > > ** ** > > Thanks,**** > > Paul**** > > ** ** > > ** ** > > ** ** > --bcaec51d2e4453f30b04ca382056 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for the detailed response Fred. =A0I 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:=A0=A0If the initiator didn'= t send any immediate data (the iSCSI Command Request PDU EDTL=3D512, but th= e data segment length is 0 and the Final bit is set), would the target have= the same options? =A0I 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). =A0I expect the residu= al reporting would remain the same regardless of whether any data was trans= ferred or not, correct?

Thanks,
Paul



<= div class=3D"gmail_quote">On Fri, Sep 21, 2012 at 8:00 AM, Knight, Frederic= k <Frederick.Knight@netapp.com> wrote:

You have a couple of choi= ces.

=A0<= /p>

For example, SBC makes se= veral statements about non-deterministic outcomes such as:

=A0<= /p>

The device = server may terminate the command before processing or after the device serv= er has transferred some or all of the data. (walking off t= he end of the device)

=A0<= u>

The degree = that the medium is altered by this command is vendor specific. (The format command)

=A0

But those aren=92t directly related.=A0 However, as you mention, FCP provides the following 3 choice:=

If the command requested that data b= eyond 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)=A0=A0=A0=A0=A0=A0 process = the command normally except that data beyond the FCP= _DL count shall not be req= uested or transferred;

b)=A0=A0=A0=A0=A0=A0 transfer= no data and return CHECK CONDITION status with the sense key set to ILLEGA= L REQUEST and the additional sense code set to INVALID FIELD IN COMMAND INF= ORMATION UNIT; or

c)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ma= y 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 COMM= AND INFORMATION UNIT.

=A0<= /p>

Case a) and c) allow the = media to be modified.=A0 Case b) implies no media alteration (since no data is transferred).<= span>=A0 Choice b) and c) include SCSI layer sense data, but choice a) includ= es only an FCP layer notification (no SCSI sense data, so a broken host (on= e that ignores residual unless a check condition exists) will assume succes= s).

=A0<= /p>

RFC5048 says:

=A0=A0 If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in th= e

=A0=A0 SCSI Response PDU as specified in [RFC3720].=A0 The Residual Count MUST

=A0=A0 be set to the numerical value of (SPDTL - EDTL).=

=A0<= /p>

SPDTL =3D the SCSI layer = transfer size; EDTL =3D the iSCSI layer transfer size.=

=A0<= /p>

Since the SCSI layer tran= sfer 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 r= esponse PDU).=A0 I couldn=92t quickly find any suggestions in RFC3720/5048 for sense = data, so I=92d suggest you go with choice b) or c) that FCP is using (I=92d= suggest staying away from choice a) since it has bad possibilities).= =A0 At least that is something hosts should already be familiar with.=

=A0<= /p>

The other list you might = use for these kinds of questions is the SCSI reflector: t10@t10.org (T10 defin= es the SCSI architecture and writes the various SCSI command standards).=

=A0<= /p>

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 Fred Knight

=A0<= /p>

=A0<= /p>

From: ips-bounces@ietf.org [mailto:ips-boun= ces@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<= u>

=A0

Not sure if this is the best place to ask, but here = goes...

=A0

How should an iSCSI target (SCSI direct-access block= device) handle the following scenario:

=A0

An initiator issues an iSCSI Command Request PDU con= taining a SCSI Write CDB with a transfer length of 1 block. =A0The iSCSI Co= mmand 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. =A0This would be a perfectly normal sing= le block write, except that the target's logical unit is formatted with= 4096-byte block size. =A0So it appears the initiator is confused and sendi= ng a single 512-byte block write to a logical unit that is formatted to 4KB block size.

=A0

Here are my thoughts:

=A0

1) The target could write the 512 bytes of immediate= data plus 3584 bytes (4096 minus 512) of whatever it wants to the media, a= nd then send an iSCSI Command Response PDU with SCSI status of Good and rep= orting an Overflow with a residual count of 3584. =A0This seems to be the most correct way of handling this s= cenario, but it seems dangerous to allow an apparently confused initiator t= o essentially corrupt data on the logical unit.

=A0

2) The target could send an iSCSI=A0Command Response= PDU with SCSI status of Check Condition, with sense data of Aborted Comman= d, Invalid Field in Command Information Unit (0x0E03). =A0This sense code i= s apparently intended for FCP (I found it mentioned in FCP-4) but it seems appropriate in this case. =A0Assuming = the target can fail the SCSI Write command this way (or some other way), sh= ould the target also report an Underflow with a residual count of 512?

=A0

Are there any other alternatives?

=A0

Thanks,

Paul

=A0

=A0

=A0


--bcaec51d2e4453f30b04ca382056--