st.conf for Quantum DAT 160

  • Follow


I am looking for a definitive st.conf entry for the Quantum DAT 160 tape
drive.  Does anyone have a pointer to this?  I am using the following:

"QUANTUM DAT   DAT160-00", "QUANTUM DAT   DAT160-00", "CFGQUANTUMDATDAT16000";
CFGQUANTUMDATDAT16000 = 2,0x34,0,0x18659,4,0x48,0x48,0x48, \
0x48,3,120,300,600,1200,600,600,18000;

Sniffing through the built in drivers, as per the man page (st (7)D) I see
the following:

chicken 103% strings /kernel/drv/sparcv9/st | grep -i 160
HP      DAT160
Quantum VS160
QUANTUM DLT VS160

Does anyone know if the Hp DAT160 is at all related to the Quantum one?

I raised a support call with Quantum, but have been going round in circles
with them for over a month now.  On top of the lack of a 3.5" front plate,
I am really not too pleased.

I have the device working, but am hoping that there is room for
improvement, as it is around 30% slower than the DAT 72 drive I replaced.

As always, any help will be much appreciated.

-- 
Dr Tristram J. Scott               
Energy Consultant                  
0
Reply tristram 3/22/2011 2:33:27 PM

Tristram Scott <tristram.scott@ntlworld.com> wrote:

> I have the device working, but am hoping that there is room for
> improvement, as it is around 30% slower than the DAT 72 drive I replaced.

Just a wild guess but are you sure you are trying to write to the drive
using compression?

We haven't used tape in a while but I sort of remember with one tape drive
we ran into something similar and had to do with some dip switches forcing
(not software control) for the compression.

When in the "software control" for compression on/off, it didn't. Other
words /dev/rmt/0n and /dev/rmt/0cn made no difference.

With it not using using the compression, it seemed the drive was taking
forever to run it's course compared to the drive it replaced. 

-bruce
bje@ripco.com
0
Reply Bruce 3/23/2011 12:17:30 PM


Bruce Esquibel <bje@ripco.com> wrote:
> Tristram Scott <tristram.scott@ntlworld.com> wrote:
> 
>> I have the device working, but am hoping that there is room for
>> improvement, as it is around 30% slower than the DAT 72 drive I replaced.
> 
> Just a wild guess but are you sure you are trying to write to the drive
> using compression?
> 

Thanks for your thoughts, Bruce.  Unfortunately, I see it being slower than
its predecessor both with and without compression, which makes me think
that compression is not the issue.

I wondered if it might be a block size issue, but my tests with dd suggest
that it doesn't care much about blocksize, as long as it is more than a few
kB.  Maybe it is just slow.


I don't know why Quantum are being so secretive about configuration
details.  They have been making tape drives for the Unix world for decades.


-- 
Dr Tristram J. Scott               
Energy Consultant                  
0
Reply tristram 3/23/2011 4:08:00 PM

Tristram Scott <tristram.scott@ntlworld.com> wrote:

> Thanks for your thoughts, Bruce.  Unfortunately, I see it being slower than
> its predecessor both with and without compression, which makes me think
> that compression is not the issue.

> I wondered if it might be a block size issue, but my tests with dd suggest
> that it doesn't care much about blocksize, as long as it is more than a few
> kB.  Maybe it is just slow.


Only other thought I had is maybe something with the termination.

That is a regular scsi device, correct?

Maybe it has built in terminators and you have another terminator on the 
cable. Usually that kills the bus from working at all but maybe it's seeing
enough data to work but erroring out constantly.

How slow is slow anyway?

I don't remember those things being speed demons, might have the numbers
wrong but 15-20GB an hour I think was about it. Took like 3 1/2 to 4 hours
to backup a 100GB file system with 80% utilization.

Maybe that was for the AIT tapes, really don't remember, heh.

-bruce
bje@ripco.com
0
Reply Bruce 3/24/2011 11:30:00 AM

Bruce Esquibel <bje@ripco.com> wrote:
> 
> Only other thought I had is maybe something with the termination.
> 

That thought had crossed my mind to, but it does all look good, and there
are no reports of errors in the logs.  I am using the same enclosure and
cables as I was for its predecessor, and they are all from Sun.

Slow is not terrible, just not fast.  I see around 2.5 MB/s, and used to
see a bit over 3 MB/s.  This is without compression.

No matter, I will persist in hassling Quantum and report back if I ever
hear anything useful from them.

Thanks for your ideas.

-- 
Dr Tristram J. Scott               
Energy Consultant                  
0
Reply tristram 3/24/2011 7:49:56 PM

On 03/22/11 10:33 AM, Tristram Scott wrote:
> I am looking for a definitive st.conf entry for the Quantum DAT 160 tape
> drive.  Does anyone have a pointer to this?  I am using the following:
>
> "QUANTUM DAT   DAT160-00", "QUANTUM DAT   DAT160-00", "CFGQUANTUMDATDAT16000";
> CFGQUANTUMDATDAT16000 = 2,0x34,0,0x18659,4,0x48,0x48,0x48, \
> 0x48,3,120,300,600,1200,600,600,18000;

Is "QUANTUM DAT   DAT160-00" the exact vendor inquiry string of the 
drive? If not, the st driver might be ignoring that entry.
0
Reply Oscar 3/24/2011 10:03:22 PM

Oscar del Rio <delrio@mie.utoronto.ca> wrote:
> On 03/22/11 10:33 AM, Tristram Scott wrote:
>> I am looking for a definitive st.conf entry for the Quantum DAT 160 tape
>> drive.  Does anyone have a pointer to this?  I am using the following:
>>
>> "QUANTUM DAT   DAT160-00", "QUANTUM DAT   DAT160-00", "CFGQUANTUMDATDAT16000";
>> CFGQUANTUMDATDAT16000 = 2,0x34,0,0x18659,4,0x48,0x48,0x48, \
>> 0x48,3,120,300,600,1200,600,600,18000;
> 
> Is "QUANTUM DAT   DAT160-00" the exact vendor inquiry string of the 
> drive? If not, the st driver might be ignoring that entry.

Yes, cut and pasted from the mt config output when the drive was first
connected (and reported as unknown, as per mt(1).

Thanks for the idea, though.

-- 
Dr Tristram J. Scott               
Energy Consultant                  
0
Reply tristram 3/25/2011 8:20:28 AM

On 03/25/11 04:20 AM, Tristram Scott wrote:
> Oscar del Rio<delrio@mie.utoronto.ca>  wrote:
>> On 03/22/11 10:33 AM, Tristram Scott wrote:
>>> I am looking for a definitive st.conf entry for the Quantum DAT 160 tape
>>> drive.  Does anyone have a pointer to this?  I am using the following:
>>>
>>> "QUANTUM DAT   DAT160-00", "QUANTUM DAT   DAT160-00", "CFGQUANTUMDATDAT16000";
>>> CFGQUANTUMDATDAT16000 = 2,0x34,0,0x18659,4,0x48,0x48,0x48, \
>>> 0x48,3,120,300,600,1200,600,600,18000;
>>
>> Is "QUANTUM DAT   DAT160-00" the exact vendor inquiry string of the
>> drive? If not, the st driver might be ignoring that entry.
>
> Yes, cut and pasted from the mt config output when the drive was first
> connected (and reported as unknown, as per mt(1).

I would double check by changing the "pretty print" field and checking 
that mt displays the string you specify when querying the drive.

Otherwise, the entry you have is similar, although not identical, to the 
HP DAT-160 coded in the st driver. Check the (open)solaris st_conf.c 
source code.

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/scsi/targets/st_conf.c
0
Reply Oscar 3/25/2011 1:46:50 PM

Oscar del Rio wrote:
> On 03/25/11 04:20 AM, Tristram Scott wrote:
> > Oscar del Rio<delrio@mie.utoronto.ca>  wrote:
> >> On 03/22/11 10:33 AM, Tristram Scott wrote:
> >>> I am looking for a definitive st.conf entry for the Quantum DAT 160 tape
> >>> drive.  Does anyone have a pointer to this?  I am using the following:
> >>>
> >>> "QUANTUM DAT   DAT160-00", "QUANTUM DAT   DAT160-00", "CFGQUANTUMDATDAT16000";
> >>> CFGQUANTUMDATDAT16000 = 2,0x34,0,0x18659,4,0x48,0x48,0x48, \
> >>> 0x48,3,120,300,600,1200,600,600,18000;
> >>
> >> Is "QUANTUM DAT   DAT160-00" the exact vendor inquiry string of the
> >> drive? If not, the st driver might be ignoring that entry.
> >
> > Yes, cut and pasted from the mt config output when the drive was first
> > connected (and reported as unknown, as per mt(1).
> 
> I would double check by changing the "pretty print" field and checking 
> that mt displays the string you specify when querying the drive.

Or inquire using scsiinfo or cdrecord (if available).

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>
0
Reply v_borchert 3/26/2011 5:56:06 AM

Oscar del Rio <delrio@mie.utoronto.ca> wrote:
> On 03/25/11 04:20 AM, Tristram Scott wrote:
>> Oscar del Rio<delrio@mie.utoronto.ca>  wrote:
>>> On 03/22/11 10:33 AM, Tristram Scott wrote:
>>>> I am looking for a definitive st.conf entry for the Quantum DAT 160 tape
>>>> drive.  Does anyone have a pointer to this?  I am using the following:
>>>>
>>>> "QUANTUM DAT   DAT160-00", "QUANTUM DAT   DAT160-00", "CFGQUANTUMDATDAT16000";
>>>> CFGQUANTUMDATDAT16000 = 2,0x34,0,0x18659,4,0x48,0x48,0x48, \
>>>> 0x48,3,120,300,600,1200,600,600,18000;
>>>
>>> Is "QUANTUM DAT   DAT160-00" the exact vendor inquiry string of the
>>> drive? If not, the st driver might be ignoring that entry.
>>
>> Yes, cut and pasted from the mt config output when the drive was first
>> connected (and reported as unknown, as per mt(1).
> 
> I would double check by changing the "pretty print" field and checking 
> that mt displays the string you specify when querying the drive.
> 
> Otherwise, the entry you have is similar, although not identical, to the 
> HP DAT-160 coded in the st driver. Check the (open)solaris st_conf.c 
> source code.
> 
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common
> /io/scsi/targets/st_conf.c

Thanks for the various ideas.  I did change the pretty print field to
confirm that it was picking up my entry. 

"QUANTUM DAT   DAT160-00", "QUANTUM DAT X DAT160-00", "CFGQUANTUMDATDAT16000";
CFGQUANTUMDATDAT16000 = 2,0x34,0,0x18619,4,0x48,0x48,0x48,0x48,3, \
120,300,600,1200,600,600,20000;

I have changed the name, adding the X, and also changed the values 0x18659
to 0x18619, and the last timeout from 18000 to 20000.

I did the reboot -- -r, and then mt config reports this:

chicken 1% mt config
"QUANTUM DAT   DAT160-00", "QUANTUM DAT X DAT160-00", "CFGQUANTUMDATXDAT16000";
CFGQUANTUMDATXDAT16000 = 2,0x34,0,0x18659,4,0x48,0x48,0x48,0x48,3,120,300,
600,1200,600,600,20000;

So it is picking up the new entry, including the moidified timeout value,
but the hex value for the flags is reverting back to 0x18659.

I am not sure what is happening there.  Perhaps there was some negotiation
between Solaris and the drive?

-- 
Dr Tristram J. Scott               
Energy Consultant                  
0
Reply tristram 3/28/2011 12:08:36 PM

9 Replies
369 Views

(page loaded in 0.089 seconds)

Similiar Articles:




7/20/2012 12:28:02 PM


Reply: