Re: [Ips] this list

"Knight, Frederick" <Frederick.Knight@netapp.com> Mon, 24 January 2011 16:06 UTC

Return-Path: <Frederick.Knight@netapp.com>
X-Original-To: ips@core3.amsl.com
Delivered-To: ips@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803293A6905 for <ips@core3.amsl.com>; Mon, 24 Jan 2011 08:06:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJOEGPnQJk9m for <ips@core3.amsl.com>; Mon, 24 Jan 2011 08:06:28 -0800 (PST)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 5A3733A68FE for <ips@ietf.org>; Mon, 24 Jan 2011 08:06:28 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.60,370,1291622400"; d="scan'208";a="509214997"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 24 Jan 2011 08:09:21 -0800
Received: from sacrsexc1-prd.hq.netapp.com (sacrsexc1-prd.hq.netapp.com [10.99.115.27]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p0OG9L5s017548; Mon, 24 Jan 2011 08:09:21 -0800 (PST)
Received: from rtprsexc2-prd.hq.netapp.com ([10.100.161.115]) by sacrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Jan 2011 08:09:21 -0800
Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.112]) by rtprsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Jan 2011 11:09:20 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 24 Jan 2011 11:09:30 -0500
Message-ID: <AC32D7C72530234288643DD5F1435D530D97D8B6@RTPMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03D7689A49@MX14A.corp.emc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ips] this list
Thread-Index: Acu7y7k5xVmZlhFaQ02bNg5x7QrKLgAD8H/gAAFIdgA=
References: <20110124133020.GN19602@belle.intranet.vanheusden.com> <7C4DFCE962635144B8FAE8CA11D0BF1E03D7689A49@MX14A.corp.emc.com>
From: "Knight, Frederick" <Frederick.Knight@netapp.com>
To: <david.black@emc.com>, <folkert@vanheusden.com>, <ips@ietf.org>
X-OriginalArrivalTime: 24 Jan 2011 16:09:20.0182 (UTC) FILETIME=[0EE07D60:01CBBBE1]
Subject: Re: [Ips] this list
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 24 Jan 2011 16:06:29 -0000

On the other hand, it depends on what CHECK CONDITION you are getting.

Can you supply the full CDB and full response (all sense data including) - status, sense key, ASC/ASCQ, data (if any).

If you are sending a badly formed CDB, they the device is perfectly within its rights to return CHECK CONDITION - but when it does, it should also return more info about what is wrong (and that will be down in the detailed bits of the returned sense data).

Invalid OP Code is not valid for a disk to return (as per previous comments), but INVALID FIELD IN CDB means you made a mistake.

	Fred Knight

-----Original Message-----
From: david.black@emc.com [mailto:david.black@emc.com] 
Sent: Monday, January 24, 2011 10:39 AM
To: folkert@vanheusden.com; ips@ietf.org
Subject: Re: [Ips] this list

That's actually more of a generic SCSI question than an iSCSI question, but anyhow ...

... if READ CAPACITY (10) doesn't work, try READ CAPACITY (16) [opcode 0x9E, service action 0x10].

OTOH, if READ CAPACITY (10) results in a Check Condition for invalid opcode, the target that issued that CC does not comply with the SCSI standards, as support for READ CAPACITY (10) is mandatory for block devices in both the SBC-2 standard and all drafts of the in-progress SBC-3 standard.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of folkert
> Sent: Monday, January 24, 2011 8:30 AM
> To: ips@ietf.org
> Subject: [Ips] this list
> 
> Hi,
> 
> Is this list available for generic iSCSI questions?
> 
> If so: some (linux iscsi target and window iStorageSErver) respond with
> valid data to Read Capacity(10) SCSI 0x25 command while for example
> nexenta store (an opensolaris system) responds with Check Condition.
> So I guess this is not the common way of determing the sector size and
> size of the device.
> Which command should I use for this?
> Thanks.
> 
> 
> Folkert van Heusden
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www.ietf.org/mailman/listinfo/ips