[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

9564.0. "A4100, DU3.2g & Boxhill Raid Controller" by SIOG::BR_MURPHY () Mon Apr 21 1997 08:45

    Has anyone out there had anything to do with Boxhill raid controllers?
    
    I have a customer who has a Boxhill raid controller. Over the weekend
    the VAR who supplied this setup a number of raidsets. However this
    controller appears to transmit on SCSI id 0, LUN 0,1,2...ad infinitum.
    Actually they created 17 LUNS. The first group of raidsets delivering 7
    lots of 5Gb disk space on SCSI ID 0, LUNS 0-6 worked fine. The next
    group of raidsets delivering 7 lots 5Gb of disk space on SCSI ID 0,
    LUNS 7-13 failed. The third group of raidsets delivering 3 lots of 5Gb
    disk space on SCSI ID 0, LUNS 14-16 also failed
    
    They say using multiple LUNS is normal & has been implemented on a
    number of different unix platforms successfully. I say this is not
    possible, due to hardware restrictions. The SCSI card (KZPSA) is only
    capable of supporting 8 SCSI target ID's, & for each target ID, 8 LUN
    numbers.
    
    They also said the Boxhill raid controller could only deliver raidsets
    via one SCSI target ID....unlike an HSZ device that can use multiple
    SCSI targets & luns. 
    
    In the end, the raidsets were delivered large 35Gb disks & partitioned
    into 5Gb filesystems using disklabel. I'm not happy with this solution,
    as any changes to the size on one filesystem, by adding more disks to
    the controller affects every other filesystem...ie 35 GB will need to
    be backed up, the disklabel re-editted & all the data restored. This is
    not a satisfactory solution at all.
    
    Can anyone help.
    
    Brendan
    
T.RTitleUserPersonal
Name
DateLines
9564.1SMURF::KNIGHTFred KnightTue Apr 22 1997 15:3514
Thats what happens when you buy a NON-SUPPORTED device
that violates the scsi spec.

The scsi-2 spec clearly states that the lun field is
a 3 bit field.  So, I'm not sure how you can have any
lun number greater than 7 (atleast I can't think of
how to do it).

If other vendors drivers also violate the scsi-2 spec,
then so be it.  We however comply with the standard and
will work correctly with devices that also comply with
the standard.

	Fred Knight
9564.2NABETH::alanDr. File System's Home for Wayward Inodes.Tue Apr 22 1997 18:474
	Ah, but would it violate the spec (such as it is) if the device
	where claiming to be SCSI-3?  SCSI-2 was as solid as quick-sand
	when vendors started claiming "compliance".  Why should they do
	any differently for SCSI-3...
9564.3Boxhill & scsi complianceSIOG::BR_MURPHYWed Apr 23 1997 05:2518
    Re 9564.1
    
    Hey!! Don't blame me for buying this stuff. I was just responding to a
    call & found it already installed.
    
    Actually, I don't believe it's a none standard scsi2-spec. I think it
    complies very well with the spec. I think the real problem is that the
    VAR's who sold it & installed it don't really know how to configure it.
    I was hoping there was someone out there who could help me sort out the
    correct configuration...or point me in the right direction for further
    information.
    
    Re 9564.2
    
    SCSI-3? Why what does the scsi3 spec have to say about LUNS, & does
    Digital supply scsi cards that conform to this standard....& are
    compatible with AS4100 running DU3.2G
    
9564.4NABETH::alanDr. File System's Home for Wayward Inodes.Wed Apr 23 1997 18:365
	I'm lead to believe that SCSI-3 increases the number of logical
	units that a target can have.  I don't know if support for this
	particular feature requires new adapters or just drivers and
	supporting host software.� I'm also lead to believe that a
	future version of Digital UNIX will be more SCSI-3 friendly.
9564.5DECWET::RWALKERRoger Walker - Media ChangersTue Apr 29 1997 20:2812
	SCSI-2, the current spec, limits the LUN to 3 bits in
	the IDENTIFY message.  This only allows a LUN range of
	0-7.  While SCSI-3 is being drafted some vendors are using
	some of its featues and some even report SCSI-3 in the
	inquire data.  Why wait for a standard to finish if it
	has good stuff, we couldn't for real time POSIX.

	To use of the SCSI-3 LUN range requires all parts of the system
	to change.  Even if you could get an adapter that works
	it doesn't fix the O/S.  We almost had it for 4.0 but oh well.
	Until all software can live without the /dev/rz5c format
	we just have to do without more LUNS.
9564.6SMURF::KNIGHTFred KnightWed Apr 30 1997 17:329
The SCSI-3 lun field is 8 bytes in length.  So yes, it
requires not only new S/W, but new H/W as well!

Also, any device that uses less than 8 bytes for the
lun field is NOT SCSI-3.  And any device that uses more
than 3 bits is NOT SCSI-2.  So, if it's not SCSI-2, and
it's not SCSI-3, .....

	Fred Knight