From owner-freebsd-scsi@FreeBSD.ORG Fri Aug 25 22:02:17 2006 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D47016A4DD; Fri, 25 Aug 2006 22:02:17 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id D378844201; Fri, 25 Aug 2006 22:02:15 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([165.236.175.187]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k7PM28gV025007; Fri, 25 Aug 2006 16:02:13 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <44EF735A.8070308@samsco.org> Date: Fri, 25 Aug 2006 16:02:02 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Studenmund References: <000201c6c7df$cb0e8a40$0200a8c0@mrbill5> <20060825204525.GA8060@nargothrond.kdm.org> <44EF64CF.2060304@samsco.org> <71A64AAF-B229-4109-BA2F-E2AC64A11060@wasabisystems.com> In-Reply-To: <71A64AAF-B229-4109-BA2F-E2AC64A11060@wasabisystems.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.5 required=3.8 tests=SPF_SOFTFAIL autolearn=no version=3.1.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: "Kenneth D. Merry" , scsi@freebsd.org Subject: Re: iSCSI/luns/check-condition X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2006 22:02:17 -0000 William Studenmund wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Aug 25, 2006, at 1:59 PM, Scott Long wrote: > >> Kenneth D. Merry wrote: >> >>> On Fri, Aug 25, 2006 at 11:37:15 -0700, William Studenmund wrote: >>> See above...CAM sets the LUN number when it does the initial probe of a >>> LUN, and when the LUN reports it is SCSI-2 or below. >>> The problem with rejecting the LUN number on the inquiry is that the >>> initiator is issuing the inquiry to find out what SCSI rev the >>> target is in >>> the first place. It has to do so in a way that will work on old and >>> new >>> targets. >>> Things work okay on LUN 0, because the LUN field is set to 0. >>> My suggestion would be to allow setting of the LUN number on the >>> inquiry >>> command only. That way the initiator can figure out what SCSI rev >>> you are >>> and do things accordingly. >>> Ken >> >> >> Are there cases where a target has multiple LUNs that will each >> report a different SCSI rev? If not, then CAM should look at the rev >> of LUN 0 of the target when deciding how to form an INQ of LUNs >0. > > > While I think there could be a difference between reported levels, if > LUN 0 reports > SCSI-1, then I think it's appropriate to not put the > LUN in the CDB. SCSI-2 mentions that the LUN field should be set to > zero as SCSI-3 may reclaim the bits (which it did). > > I believe that by the time LUN 0 has been probed, the system should > have enough information to figure out if the device is SCSI-1, SCSI-2. > or SCSI-3 (i.e. sam-X, spc-Y, etc.). I think that Scott's suggestion is > good; if LUN 0 is SCSI-1, fill in the LUN in the CBD. If LUN 0 is > > SCSI-1, don't. > > Also, while probing LUN 0, it's probably best to perform a REPORT LUNS > command. If it succeeds, you 1) don't need to blindly probe, and 2) you > know that you shouldn't put the LUN in the CDB (REPORT LUNS appeared > in SPC, which is SCSI-3). > The REPORT_LUNS angle has been discussed many times in the past. The problem is that it's a risky command without the right heuristics. Older SCSI devices are notorious for going down in flames if given a CDB that they don't understand, so we can't universally send a REPORT_LUNS to every target that responds on LUN 0. We've discussed adding some heuristics to look at the rev field and decide from there, but that's only part of the problem. The other part of the problem involves tackling the CAM probe state machine to handle both the current sequential scan as well as a REPORT_LUNS enumeration. That's not an exceptionally hard task, it just takes a bit of work. Scott