This is a cryptographically signed message in MIME format.
--------------ms050306000804080307010000
Content-Type: multipart/alternative;
boundary="------------060605010606030303060400"
This is a multi-part message in MIME format.
--------------060605010606030303060400
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Ahh, now I understand. Your theory doesn't sound unreasonable.
Donaldson, Mark wrote:
>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
===================================
--------------060605010606030303060400
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Ahh, now I understand. Your theory doesn't sound unreasonable.<br>
<br>
Donaldson, Mark wrote:<br>
<blockquote type="cite"
cite="mid6956D00165F4CB4583BB9CC33D77364F1D832D AT denca00.corp.exactis DOT
com">
<pre wrap="">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 [<a class="moz-txt-link-freetext" href="mailto:ssesar AT
mitre DOT org">mailto:ssesar AT mitre DOT org</a>]
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:
</pre>
<blockquote type="cite">
<pre wrap="">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 [<a class="moz-txt-link-freetext"
href="mailto:ssesar AT mitre DOT org">mailto:ssesar AT mitre DOT org</a>]
*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:
</pre>
<blockquote type="cite">
<pre wrap="">Yes, that is the inquiry string that comes from the drive
(or vendor
string).
-----Original Message-----
From: Donaldson, Mark [<a class="moz-txt-link-freetext"
href="mailto:Mark.Donaldson AT experianems DOT com">mailto:Mark.Donaldson AT
experianems DOT com</a>]
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:
</pre>
<blockquote type="cite">
<pre wrap="">grep -v "^#" /kernel/drv/st.conf
</pre>
</blockquote>
<pre wrap="">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 - <a class="moz-txt-link-abbreviated"
href="mailto:Veritas-bu AT mailman.eng.auburn DOT edu">Veritas-bu AT
mailman.eng.auburn DOT edu</a>
<a class="moz-txt-link-freetext"
href="http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu";>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu</a>
_______________________________________________
Veritas-bu maillist - <a class="moz-txt-link-abbreviated"
href="mailto:Veritas-bu AT mailman.eng.auburn DOT edu">Veritas-bu AT
mailman.eng.auburn DOT edu</a>
<a class="moz-txt-link-freetext"
href="http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu";>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu</a>
</pre>
</blockquote>
<pre wrap="">
--
===================================
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: <a class="moz-txt-link-abbreviated" href="mailto:ssesar AT mitre DOT
org">ssesar AT mitre DOT org</a>
===================================
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
===================================
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: <a class="moz-txt-link-abbreviated" href="mailto:ssesar AT mitre DOT
org">ssesar AT mitre DOT org</a>
===================================</pre>
</body>
</html>
--------------060605010606030303060400--
--------------ms050306000804080307010000
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHgTCC
AkwwggG1oAMCAQICAhk0MA0GCSqGSIb3DQEBBAUAMEsxEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRUwEwYDVQQDEwxjYS5taXRyZS5vcmcw
HhcNMDMwMzI3MTI1MTQ3WhcNMDQwOTE3MTI1MTQ3WjB4MRIwEAYDVQQKEwltaXRyZS5vcmcx
DzANBgNVBAsTBnBlb3BsZTEWMBQGCgmSJomT8ixkAQETBnNzZXNhcjEYMBYGA1UEAxMPU2Vz
YXIsU3RldmVuIEwuMR8wHQYJKoZIhvcNAQkBFhBzc2VzYXJAbWl0cmUub3JnMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQCsMFG7P8BkusNRNWmoqH0y67h3ZrYit9OIJzHDuJHdQPCE
wMYZ9ij4QERUL4RJGwuBt+pj9tkswVi3R7qLKqodNMsiXhIBk25n9F9yO3KHyTlBR4PTW3dt
WARent/Gr5nWR9fnQVwbVEYeqbRSQkLrfRw9mOKfbR86TiV2CJX4dwIDAQABoxIwEDAOBgNV
HQ8BAf8EBAMCBeAwDQYJKoZIhvcNAQEEBQADgYEAR6PVaJjQRwG9Wrb/eEWlG1Ks9UJNv9UE
YYhEO4XXwgf41xe7SIZUQbb40ulX6nklZ9u9dTENFfGPamO9sN2C8Ys0dionUq7P7toCohXS
txBIbwgE7kg7UIzAmKbuG8pV7iUY5g64nXcgb4IvjJDU73TC9RnP8hN5LjnsP40fHJ0wggJM
MIIBtaADAgECAgIZNDANBgkqhkiG9w0BAQQFADBLMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAc
BgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEVMBMGA1UEAxMMY2EubWl0cmUub3JnMB4X
DTAzMDMyNzEyNTE0N1oXDTA0MDkxNzEyNTE0N1oweDESMBAGA1UEChMJbWl0cmUub3JnMQ8w
DQYDVQQLEwZwZW9wbGUxFjAUBgoJkiaJk/IsZAEBEwZzc2VzYXIxGDAWBgNVBAMTD1Nlc2Fy
LFN0ZXZlbiBMLjEfMB0GCSqGSIb3DQEJARYQc3Nlc2FyQG1pdHJlLm9yZzCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEArDBRuz/AZLrDUTVpqKh9Muu4d2a2IrfTiCcxw7iR3UDwhMDG
GfYo+EBEVC+ESRsLgbfqY/bZLMFYt0e6iyqqHTTLIl4SAZNuZ/Rfcjtyh8k5QUeD01t3bVgE
Xp7fxq+Z1kfX50FcG1RGHqm0UkJC630cPZjin20fOk4ldgiV+HcCAwEAAaMSMBAwDgYDVR0P
AQH/BAQDAgXgMA0GCSqGSIb3DQEBBAUAA4GBAEej1WiY0EcBvVq2/3hFpRtSrPVCTb/VBGGI
RDuF18IH+NcXu0iGVEG2+NLpV+p5JWfbvXUxDRXxj2pjvbDdgvGLNHYqJ1Kuz+7aAqIV0rcQ
SG8IBO5IO1CMwJim7hvKVe4lGOYOuJ13IG+CL4yQ1O90wvUZz/ITeS457D+NHxydMIIC3TCC
AkagAwIBAgIBGTANBgkqhkiG9w0BAQUFADBPMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNV
BAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEZMBcGA1UEAxMQcm9vdGNhLm1pdHJlLm9yZzAe
Fw0wMTA2MTIxNzMzNTVaFw0wNTAzMjcwNTAwMDBaMEsxEjAQBgNVBAoTCW1pdHJlLm9yZzEe
MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRUwEwYDVQQDEwxjYS5taXRyZS5vcmcw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM6K1dCL4VTShZUcn1sDzOvDo0hTp025906W
mOnGhLx/2QEUmb7pZS77+T1/nqmthxtoZXwjBYWPTFCnoD/1xXks28NdGVZRvRDOtEbpDvTw
adtbzfXQp/fwFNPcnL8+UgyM7G2ZnakPNDTAf0ZcY4Z4P+g6177smfPplwYPWdZHAgMBAAGj
gcwwgckwEQYJYIZIAYb4QgEBBAQDAgCHMA4GA1UdDwEB/wQEAwIBxjAdBgNVHQ4EFgQUqTMT
u3doqXs3nKOJAaaKMXIkFmkwHwYDVR0jBBgwFoAUmlNmx6uDJWPk4VsmGXW8aow0P10wEgYD
VR0TAQH/BAgwBgEB/wIBATBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vZW1wbG95ZWVzaGFy
ZS5taXRyZS5vcmcvbC9sbW9zY2EvdHJhbnNmZXIvcm9vdGNhLWRldi5jcmwwDQYJKoZIhvcN
AQEFBQADgYEAjmInqADGLuA0ykaWRKw8uPzdLnQtSy9Cs2WesgNg1Cg4jpBALIbcfD1D6isN
BgrQOIB85sFgnDZh17E8fdaEohf/upoWac0JrNt9tXJh+J60LZplTSaemFpseFEopWJm5uun
oKOhvVAO/e2QtZpvmc2EzINLNRIwDVd1UII5qpgxggJyMIICbgIBATBRMEsxEjAQBgNVBAoT
CW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRUwEwYDVQQDEwxj
YS5taXRyZS5vcmcCAhk0MAkGBSsOAwIaBQCgggF3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDgxNDE5MDQ1MlowIwYJKoZIhvcNAQkEMRYEFDj4irLZ
zEG4zD4Q7zjRfAaqy3NcMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMGAGCSsGAQQB
gjcQBDFTMFEwSzESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBB
dXRob3JpdHkxFTATBgNVBAMTDGNhLm1pdHJlLm9yZwICGTQwYgYLKoZIhvcNAQkQAgsxU6BR
MEsxEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5
MRUwEwYDVQQDEwxjYS5taXRyZS5vcmcCAhk0MA0GCSqGSIb3DQEBAQUABIGAWkZxM+4kDYh0
yZ/DZWRumgcTpxs2y85GERrqRu99FE5zOofMHEjeo27TrbxTlECWmAlqmP/wZJmdh1z1UXtl
HhngDMEKvCwHLAv9KLQFgG+7QfMOIiLq7Kl+FrnBEj2HvRCyQcwPIbCTZgujUw9sZ532JSYm
heBeM1uS9LuPO4kAAAAAAAA=
--------------ms050306000804080307010000--
|
