[Ips] Data Out residual overflow/underflow handling
Paul Hughes <phughes@solidfire.com> Fri, 21 September 2012 03:21 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 ADD0621E80A6 for <ips@ietfa.amsl.com>; 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 <ips@ietfa.amsl.com>; 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 <ips@ietf.org>; Thu, 20 Sep 2012 20:21:32 -0700 (PDT)
Received: by vcbfo14 with SMTP id fo14so3653866vcb.31 for <ips@ietf.org>; 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: <CAGBQytv=iMoqW372kYs1Ltf=Wd4GVdCytOa2hJdEX7Nu9JTT_g@mail.gmail.com>
From: Paul Hughes <phughes@solidfire.com>
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 <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 03:21:33 -0000
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
- [Ips] Data Out residual overflow/underflow handli… Paul Hughes
- Re: [Ips] Data Out residual overflow/underflow ha… Knight, Frederick
- Re: [Ips] Data Out residual overflow/underflow ha… Paul Hughes