st.conf for Quantum DAT 160
Tristram Scott
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
Bruce Esquibel
> 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
b...@ripco.com
Tristram Scott
> Tristram Scott <tristra...@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.
Bruce Esquibel
> 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
b...@ripco.com
Tristram Scott
>
> 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.
Oscar del Rio
> 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.
Tristram Scott
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.
Oscar del Rio
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
Volker Borchert
> On 03/25/11 04:20 AM, Tristram Scott wrote:
> > Oscar del Rio<del...@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 <mc...@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <v_bor...@despammed.com>
Tristram Scott
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?
Tristram Scott
responding to a request I made through their knowledge base. The essence
of his reply is that the Quantum DAT 160 is in fact the HP DAT 160, and so
we can follow the configuration for that device. The (wrapped) URL below
gets you on the right track.
http://www.hp.com/products1/storage/compatibility/tapebackup/
ThirdParty/index.html
The suggestion from the "HP DDS/DAT drives UNIX, Linux and OpenVMS
configuration guide" pdf document is to use the following:
tape-config-list = "HP DAT160","HP DAT160 tape drive","HP-DAT160";
HP-DAT160 = 1,0x34,0,0x18679,1,0x00,0,60,300,600,1200,600,600,18000;
There is a mistake there, in that the configuration line is in version 2
format, but they have a 1 for the version. Messages on the console pointed
this out to me.
I have used the following. I attempted to reload the module, but it seemed
not to want to read the modified st.conf, so I reverted to reboot -- -r.
tape-config-list= "SONY SDT-9000", "SONY 4mm DDS3", "SONY_DAT",
"QUANTUM DAT DAT160-00", "QUANTUM DAT X DAT160-00", "QUANTUMDAT160X";
# The following is from the HP DAT 160, which is the same machine.
QUANTUMDAT160X = 2,0x34,0,0x18679,1,0x00,0,60,300,600,1200,600,600,20000;
chicken 6% mt config
"QUANTUM DAT DAT160-00", "QUANTUM DAT X DAT160-00", \
"CFGQUANTUMDATXDAT16000";
CFGQUANTUMDATXDAT16000 = 2,0x34,0,0x18659,4,0x00,0x00,0x00,0x00,0,60,\
300,600,1200,600,600,20000;
It has loaded the configuration I gave it, with the name "QUANTUM DAT X
DAT160-00", and the last timeout being 20000 where the default would be
18000.
I still see slow data transfer rates, between 2 and 2.5 MB/s, but I guess
that is life with this drive and these tapes (DAT 72). I will track down a
DAT 160 tape and see what can be done with that.
Thanks to all who offered advice. It was good, also, to finally get
something useful out of Quantum, but really a shame they were not a bit
faster on the response, and certainly not good that a direct request to
their support line got me nowhere.
Tristram Scott
>
> I still see slow data transfer rates, between 2 and 2.5 MB/s, but I guess
> that is life with this drive and these tapes (DAT 72). I will track down a
> DAT 160 tape and see what can be done with that.
>
down a cleaning tape for this drive, and also a DAT 160 data tape. These
are in the order of GBP 20.00 each, and I still have quite a few unused DAT
72 tapes, which is why I haven't spent money on new tapes until now.
The cleaning tape did the trick, all the I/O errors are gone.
The DAT 160 tapes are 8mm, c.f. the 4mm of DAT 72 and its predecessors. It
seems the DAT 160 drive can handle both. Data transfer rates with the 8mm
DAT 160 tape are much improved. Around 7 MB/s uncompressed, 14 MB/s
compressed. Still crappy slow with the DAT 72, but I certainly can't
complain about the speed with the DAT 160 media.