No - I'm suggesting that the output from sgscan (which I think is returning
the vendor ID string) might have to be a dead-on match with the st.conf
first field (Vendor ID) information - that this is the key-value in the
lookup of the additional setup parameters farther down in the st.conf file.
-----Original Message-----
From: Steven L. Sesar [mailto:ssesar AT mitre DOT org]
Sent: Thursday, August 14, 2003 12:54 PM
To: Donaldson, Mark
Cc: David Chapa; Veritasbu (E-mail)
Subject: Re: [Veritas-bu] Mismatch between sgscan output & st.conf
entry?
Right, but are you suggesting then, that sgscan will read from st.conf,
only if the drives in question are non-DLT? Perhaps, I'm
misunderstanding something.
Donaldson, Mark wrote:
> Sun will tell your that the DLT drives are supported as-is and not
> required in the st.conf file. Your experience may be proof of that
> statement. My problem children are my Ultrium LTO's.
>
> -M
>
> -----Original Message-----
> *From:* Steven L. Sesar [mailto:ssesar AT mitre DOT org]
> *Sent:* Thursday, August 14, 2003 12:36 PM
> *To:* David Chapa
> *Cc:* Donaldson, Mark; Veritasbu (E-mail)
> *Subject:* Re: [Veritas-bu] Mismatch between sgscan output &
> st.conf entry?
>
> I don't think that it's read from st.conf.
>
> I use SDLT220's all over, and have no entries in st.conf for them,
> as they are unneccesary.
>
> However, view my sgscan output:
>
> /dev/sg/c0t20l0: Changer: "STK L700"
> /dev/sg/c0t20l1: Tape (/dev/rmt/0): "QUANTUM SuperDLT1"
> /dev/sg/c0t20l2: Tape (/dev/rmt/1): "QUANTUM SuperDLT1"
> /dev/sg/c0t20l3: Tape (/dev/rmt/2): "QUANTUM SuperDLT1"
> /dev/sg/c0t20l4: Tape (/dev/rmt/3): "QUANTUM SuperDLT1"
> /dev/sg/c0t21l0: Tape (/dev/rmt/4): "QUANTUM SuperDLT1"
> /dev/sg/c0t21l1: Tape (/dev/rmt/5): "QUANTUM SuperDLT1"
> /dev/sg/c0t21l2: Tape (/dev/rmt/6): "QUANTUM SuperDLT1"
> /dev/sg/c0t21l3: Tape (/dev/rmt/7): "QUANTUM SuperDLT1"
> /dev/sg/c0t22l0: Changer: "STK L180"
> /dev/sg/c0t22l1: Tape (/dev/rmt/8): "QUANTUM SuperDLT1"
> /dev/sg/c0t22l2: Tape (/dev/rmt/9): "QUANTUM SuperDLT1"
> /dev/sg/c0t22l3: Tape (/dev/rmt/10): "QUANTUM SuperDLT1"
> /dev/sg/c0t23l0: Tape (/dev/rmt/12): "QUANTUM SuperDLT1"
> /dev/sg/c0t23l1: Tape (/dev/rmt/13): "QUANTUM SuperDLT1"
> /dev/sg/c1t22l4: Tape (/dev/rmt/11): "QUANTUM SuperDLT1"
>
> David Chapa wrote:
>
>>Yes, that is the inquiry string that comes from the drive (or vendor
>>string).
>>
>>-----Original Message-----
>>From: Donaldson, Mark [mailto:Mark.Donaldson AT experianems DOT com]
>>Sent: Wednesday, August 13, 2003 11:51 AM
>>To: Veritasbu (E-mail)
>>Subject: [Veritas-bu] Mismatch between sgscan output & st.conf entry?
>>
>>I've got this (potential) mismatch between my "sgscan tape" output & the
>>st.conf file (Solaris 8). If I udnerstand correctly, the name returned
>>in
>>the third field of sgscan for a tape should be the same as the first
>>field
>>of the st.conf "tape-config-list" entry for that device.
>>
>>Can somebody confirm this?
>>
>>If this is the case, it could be the root of some problems of mine. I
>>may
>>not be running an appropriate set of parameters for my LTO drives.
>>
>>If this is not the case, what command should I be using to query the
>>drive
>>identification to compare against the st.conf file?
>>
>>Advise anyone?
>>-M
>>
>>Here's "sgscan tape":
>>/dev/sg/c1t3l1: (/dev/rmt/0): "HP Ultrium 1-SCSI"
>><snip>
>>/dev/sg/c1t5l2: (/dev/rmt/8): "QUANTUM SuperDLT1"
>>
>>Here's the relevant st.conf lines:
>>
>>
>>>grep -v "^#" /kernel/drv/st.conf
>>>
>>>
>>
>>tape-config-list=
>>"HP Ultrium", "HP Ultrium", "HP_LTO",
>>"QUANTUM SuperDLT1", "Quantum SDLT 220", "SDLT_220";
>>
>>HP_LTO = 1,0x36,0,0x1d639,4,0x00,0x00,0x00,0x00,3;
>>SDLT_220 = 1,0x38,0,0x1d639,4,0x90,0x91,0x90,0x91,3;
>>
>>_______________________________________________
>>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
>>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>>
>>_______________________________________________
>>Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
>>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>>
>>
>
>
>--
>===================================
>
> Steven L. Sesar
> Senior Operating Systems Programmer/Analyst
> UNIX Application Services R10A
> The MITRE Corporation
> 202 Burlington Road - KS101
> Bedford, MA 01730
> tel: (781) 271-7702
> fax: (781) 271-2600
> mobile: (617) 893-9635
> email: ssesar AT mitre DOT org
>
>===================================
>
--
===================================
Steven L. Sesar
Senior Operating Systems Programmer/Analyst
UNIX Application Services R10A
The MITRE Corporation
202 Burlington Road - KS101
Bedford, MA 01730
tel: (781) 271-7702
fax: (781) 271-2600
mobile: (617) 893-9635
email: ssesar AT mitre DOT org
===================================
|