Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Apr 2002 15:14:30 -0700 (PDT)
From:      Matthew Jacob <mjacob@feral.com>
To:        "Kenneth D. Merry" <ken@kdm.org>
Cc:        "Justin T. Gibbs" <gibbs@scsiguy.com>, scsi@FreeBSD.ORG
Subject:   Re: is there a reason that da should *not* drive type STORAGE ARRAY
Message-ID:  <Pine.BSF.4.21.0204161510160.72130-100000@beppo>
In-Reply-To: <20020415161248.A72009@panzer.kdm.org>

next in thread | previous in thread | raw e-mail | index | archive | help

Oh- yeah- my mind wouldn't wrap itself around this paragraph. I'm certainly
still a bit confused about it.

I have to find out if the HP XP-512 has the SCCS bit set. We can and did
change the type to DIRECT ACCESS, and the client I'm currently working with is
not that interested in the more theoretical aspects of why there wasn't a
device driver that would just drive the XP-512. I may be able to get a couple
minutes to get this changed back so I can find out- but this is a 500K$ plus
piece of equipment and access to it is somewhat restricted.

At any rate, you've convinced me that a blind change to da(4) isn't in order.

-matt



On Mon, 15 Apr 2002, Kenneth D. Merry wrote:

> On Mon, Apr 15, 2002 at 15:44:43 -0600, Justin T. Gibbs wrote:
> > >
> > >Whilst dorking with an HP XP-512 storage arrage array on Fibre Channel, I
> > >found that it defaults to type STORAGE ARRAY (not DIRECT ACCESS). However, the
> > >DIRECT ACCESS commands work fine.
> > >
> > >Is there a reason why da(4) should *not* drive devices of type STORAGE ARRAY?
> > 
> > Fear of the unknown.  What differentiates a STORAGE ARRAY from any
> > other DIRECT ACCESS device?  Is the assumption that they are essentially
> > the same always valid?
> 
> The da(4) driver doesn't attach to storage array (type 0xc) devices because
> they aren't supposed to be direct access type devices, at least in the
> generic case.
> 
> If they're supposed to act like direct access devices, they should report
> inquiry data that indicates that, I think.  This is from section 5.2.1.1 of
> the SCC-2 (rev 04) draft:
> 
> =============
> "All SCSI storage arrays shall accept LUN_Z as a valid address. For SCSI
> storage arrays LUN_Z shall be the logical unit that an application client
> addresses to configure an SCSI storage array and to determine
> information about the target and the logical units contained within the
> target. INQUIRY commands sent to LUN_Z shall return standard inquiry data
> with the SCCS bit set to one (See SCSI Primary Commands - 2). If
> the LUN_Z supports only the array controller commands defined within this
> standard, INQUIRY commands sent to LUN_Z shall return a device type of
> array controller device.  Otherwise, INQUIRY commands sent to LUN_Z shall
> return a device type indicating the model defining the additional commands
> supported.  Support for LUN_Z with a device type other than array controller
> device is vendor specific.
> 
> The peripheral device address method shall be used when addressing the
> LUN_Z of an SCSI storage array (see 5.2.1.2.3)."
> =============
> 
> So it looks like it should be reporting a type of direct access, with the
> SCCS bit turned on.
> 
> You might want to see whether there is some mode you can turn on in the
> controller to make it expose the arrays it manages.  (Or have it tell the
> OS it is a direct access device instead of a storage array device.)
> 
> Ken
> -- 
> Kenneth Merry
> ken@kdm.org
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0204161510160.72130-100000>