Hey, all
For giving me insight, thanks to
John DiMarco <jdd@cs.toronto.edu>
Damian McGuckin <damianm@esi.COM.AU>
and to those who will answer in the future and to those who I may have
missed due to email overload.
--------------
Here was my original posting:
I have a SS10 running Solaris 2.4. In it is an Sbus fast-wide SCSI
(DWIS) card. With this card I have connected four fast-wide DLT 4700
tape drives.
Each drive has a max transfer rate of 3.0 MB/s write, 2.5 MB/s read in
compressed mode, according to the manufacturer.
According to SunSolve InfoDoc 14075, SCSI Primer, fast-wide SCSI has a
throughput of <= 20 MB/s
I'm trying to do a tape-to-tape copy, using two of the drives, using the
tcopy command, of a CompacTape IV 40GB tape, but it is taking awfully
long, more than 9 hours. I'm using /dev/rmt/?cbn device files,
(/dev/rmt/11cbn, for example, points to
.../../devices/iommu@f,e0000000/sbus@f,e0001000/QLGC,isp@2,10000/st@2,0:cbn).
Using the slowest transfer rate above, of 2.5 MB/s, I should be able to
copy this tape in less than 5 hours (40GB * (1024MB/1GB) * (1s/2.5MB) *
(1min/60s) * (1hr/60min)), right?
Why is this taking much longer? Is there something I'm missing? Does
data go through the Sbus? Does the Sbus have a max throughput?
--------------
Here are the answers I got:
>From Damian:
The rate you get will be dependent on the quality of the device driver.
We see 2.5Mb/sec on a DEC alpha but only 2.1Mb/sec on a SUN. Don't
believe technical specs from suppliers will work in all cases, if any.
Unless you have double buffering and async I/O, it takes 4.5hrs to read
it
and 4.5hrs to write it and you won't get 2.5Mb/sec either.
Sbus speed is so fast relative to the speed of the transfer as to be
irrelevant.
However, if you got a RAIT controller which can write to the 4 drives
in parallel, then that is a whole new ball game. But then, it is not
addressing the same issue.
>From John:
The Sbus has far more bandwidth than a SCSI bus; it's almost certainly
not
your bottleneck. My guess is that tcopy isn't streaming the tapes
properly.
You might attach a truss to tcopy to see what it's doing. The "obvious"
way to write a tape copy program (read in some data, then write it out,
then read in more) isn't enormously fast because it likely stops and
starts
the tapes for each chunk.
---------------
Here's what I did:
>From Damian's answer, I looked into the driver. I found that in the
/kernel/drv/st.conf file, the buffering entry was sure enough
commented. This was done by a software in the system that "emphatically
recommends *against* uncommenting the 'tape-driver-buffering' line." Oh
well, I guess I'll have to live with this.
>From John's answer, I truss-ed tcopy and it reads chunks from file
descriptor a and writes that chunks to file descriptor b. So, it reads
then writes, reads some more and writes some more.
---------------
What I'm planning to do:
Live with it and just script-automate.
Thanks again...
--/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ / Ted Marigomen Philips Semiconductors / / tmarigom@trimedia.scs.philips.com Trimedia UNIX Support / / 408.991.3053 811 E Arques, MS 71 / / 408.991.4040 fax Sunnyvale, CA 94088-3409 / ~~~~~~~~~/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/~~~~~~~~~~~~ / The mind of a quiet person is very noisy. / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:55 CDT