compressed SDLT capacity
B Hobbs
system. The following is my SWAG of an answer.
System configuration:
OpenVMS V7.1
VAX emulator Charon-VAX/XL (Plus) V 3.1 B 50 (VAX 4000 model 108)
$ show cpu lists VAX 4000-105A
Windows Server 2003 SP1, v 5.2
HP ProLiant DL385, AMD 64 Opertron
HP 160/320 GB SDLT, SCSI connection
actually a Quantum SDLT 320 under the bezel
VMS thinks the SDLT is a TK50 (about seven generations apart?)
It takes my system almost three hours to complete a INITIALIZE/ERASE
of an SDLT I cartridge in the HP SDLT 320 drive. The backup script
writes some 30 files totaling 40 GB to the SDLT each night. A
DIRECTORY of the SDLT with one night's worth of backup takes about
eight minutes, two night's about sixteen minutes, etc.. I have not
yet filled up an SDLT cartridge.
I assume that when I do a INITIALIZE/ERASE, VMS sends a SCSI erase
command to the drive and VMS does other stuff until the drive signals
that the erase command is complete -- the drive does the work and the
SCSI bus is quiet. If this is correct, then the equivalent of VMS's
INITIALIZE/ERASE on other OSes would also take almost three hours for
a SDLT I cartridge in a HP SDLT 320 drive.
I am using an emulator. Can we get a few figures from non-emulated
VMS systems and other OSes? Maybe list the drive make and model,
cartridge type, OS, hardware, and the amount of time to INITIALIZE/
ERASE (or equivalent command).
How does a DIRECTORY of the SDLT work? Does the tape drive send all
the data to VMS and VMS sorts thru the data to assemble something like
a directory listing? That would be 40 GB per backup set going over
the SCSI bus. Or does the drive look for specific directory entries
on the tape and just send those? That would be about 30 directory
entries per backup set for my system, probably a couple megabytes. Or
is there something else going on? Somewhere I saw that there is a
directory area at the beginning of the tape, but I suspect that the
main data area of the tape is involved because the more data I put on
the tape, the longer a DIRECTORY takes.
Let's see if I can figure out how much of my data a SDLT cartridge can
hold ... with a few assumptions.
The Quantum SDLT 320 specs ( http://downloads.quantum.com/sdlt320/8185002A04.pdf
) are
tape length is 1800 feet, 1765 feet usable for data
448 physical tracks, 56 logical tracks (8 track head)
read / write tape speed of 122 inches per second
1,765 feet x 12 inches per foot = 21,180 inches of tape
21,180 inches x 56 logical tracks = 1,186,080 inches of logical track
per tape
1,186,080 inches / 122 inches per second = 9,721.97 seconds to go from
beginning-of-tape (BOT) to end-of-tape (EOT)
9,721.97 seconds / 60 seconds per minute = 162.03 minutes BOT to EOT
162.03 minutes / 60 minutes per hour = 2.70 hours BOT to EOT
I suspect it takes a few seconds to reverse direction at the end of
each of the 56 logical tracks, so three hours (180 minutes) should be
pretty close. It does say that read and write are the same speed, and
I assume that the INITIALIZE/ERASE and DIRECTORY commands are working
at full speed with no stops.
162.03 minutes / 8 minutes to DIRECTORY one backup set = 20.25 backup
file sets per tape on my system
Wow! I think the max number of backup sets on a tape has been five or
six before the tape was INITed.
20.25 backup file sets * 40 GB in my backup file set = 810 GB per tape
on my system
810 GB / 160 GB uncompress SDLT capacity = 5.0625 : 1 compression on
my system
If I did this correctly, I should be able to put about 800 GB of my
backups on one SDLT I cartridge. My backup script does a DIRECTORY
before and after the backups, so I should be able to track how full
the tape is by the amount of time the DIRECTORY takes.
I found the specs in Standard ECMA-320 (
http://www.ecma-international.org/publications/standards/Ecma-320.htm
) to be close to Quantum's.
I await someone to point out where I screwed up my calculations or
assumptions.
I plan to verify that I can get around 800 GB on a SDLT. Let's
see ... 20 backup sets ... 13 cartridges on hand ... change cartridge
5 times a week ... errr, carry the square root of -2 ... it'll take
about a year to fill up those cartridges.
-- Bill Hobbs
Bob Koehler
>
> I assume that when I do a INITIALIZE/ERASE, VMS sends a SCSI erase
> command to the drive and VMS does other stuff until the drive signals
> that the erase command is complete -- the drive does the work and the
> SCSI bus is quiet.
INITIALIZE/ERASE is generic across a lot of things that don't
implement an erase command. There's a very good chance that it's
writing a pattern to the tape. If you use different options, I
think you can convince it to write more than one pattern.
> How does a DIRECTORY of the SDLT work? Does the tape drive send all
> the data to VMS and VMS sorts thru the data to assemble something like
> a directory listing?
DIRECTORY of a labeled tape reads data from the file headers. On
a labeled tape there are three physical files for each logical file.
The first physical file contains the begining of file header. The
second physical file contains the file data. The third physical file
is the end of file header.
In order to get directory information from a tape, VMS reads the
first physical file, does a skip over the second file, and reads the
third physical file, for each logical file that shows up once in a
DIRECTORY listing.
A lot of modern tape drives are optimized for data flow, not
positioning. Skipping files is a positioning operation. There have
been drives supported by VMS that did not implement a skip operation
and VMS would actually read all the data in order to implement a
skip.
B Hobbs
Koehler) wrote:
> In article <36d33800-965f-4e70-a1c9-c2a309939...@u18g2000pro.googlegroups.com>, B Hobbs <bdhobb...@acm.org> writes:
>
> > I assume that when I do a INITIALIZE/ERASE, VMS sends a SCSI erase
> > command to the drive and VMS does other stuff until the drive signals
> > that the erase command is complete -- the drive does the work and the
> > SCSI bus is quiet.
>
> INITIALIZE/ERASE is generic across a lot of things that don't
> implement an erase command. There's a very good chance that it's
> writing a pattern to the tape. If you use different options, I
> think you can convince it to write more than one pattern.
With my VMS 7.1 treating the SDLT tape drive as a TK50, I suppose it
would depend on the SCSI commands that a TK50 drive could handle and
how the driver is programmed. Anyone have a link to a TK50 manual
listing the SCSI commands?
>
> > How does a DIRECTORY of the SDLT work? Does the tape drive send all
> > the data to VMS and VMS sorts thru the data to assemble something like
> > a directory listing?
>
> DIRECTORY of a labeled tape reads data from the file headers. On
> a labeled tape there are three physical files for each logical file.
> The first physical file contains the begining of file header. The
> second physical file contains the file data. The third physical file
> is the end of file header.
>
> In order to get directory information from a tape, VMS reads the
> first physical file, does a skip over the second file, and reads the
> third physical file, for each logical file that shows up once in a
> DIRECTORY listing.
>
> A lot of modern tape drives are optimized for data flow, not
> positioning. Skipping files is a positioning operation. There have
> been drives supported by VMS that did not implement a skip operation
> and VMS would actually read all the data in order to implement a
> skip.
Again, I suspect I'm limited to what a TK50 can do. Though my "TK50"
is faster and holds more than your TK50! ;-)
Hmmm, I wonder if there is a way I can peek at what is happening on
the SCSI bus? Ok, who took my tricorder?!? It has ... err, unique
images of ... uhh, medical value of certain crew members.
-- Bill Hobbs
AEF
> On Nov 23, 5:10 am, koeh...@eisner.nospam.encompasserve.org (Bob
>
> Koehler) wrote:
> > In article <36d33800-965f-4e70-a1c9-c2a309939...@u18g2000pro.googlegroups.com>, B Hobbs <bdhobb...@acm.org> writes:
>
> Hmmm, I wonder if there is a way I can peek at what is happening on
> the SCSI bus? Ok, who took my tricorder?!? It has ... err, unique
> images of ... uhh, medical value of certain crew members.
>
> -- Bill Hobbs
Wouldn't Star Trek medicine be great?! Your doctor simply moves that
little thing that goes woo woo woo woo woo across your chest. And just
like that, he already has the syringe loaded with the correct hypo.
Then he gives you the shot right through your shirt!
But AEF, what if it's a strange alien disease?
No problem. Withing 60 minutes they'll have come up with a cure and
you're good to go.
AEF
Bob Koehler
>
> With my VMS 7.1 treating the SDLT tape drive as a TK50, I suppose it
> would depend on the SCSI commands that a TK50 drive could handle and
> how the driver is programmed. Anyone have a link to a TK50 manual
> listing the SCSI commands?
A TK50 is not a SCSI device, there has to be a controller between
it and a SCSI bus, so it's a matter of what commands that controller
implements.
> Again, I suspect I'm limited to what a TK50 can do. Though my "TK50"
> is faster and holds more than your TK50! ;-)
My TK50 isn't on a SCSI bus, er, well, most of them aren't.
Bob Koehler
>
> No problem. Withing 60 minutes they'll have come up with a cure and
> you're good to go.
Not if you're wearing a red shirt. Red shirts get the Republican
plan.
B Hobbs
Koehler) wrote:
> In article <09bbf195-3cab-47c5-88e4-5d57e00d6...@u25g2000prh.googlegroups.com>, B Hobbs <bdhobb...@acm.org> writes:
>
> > With my VMS 7.1 treating the SDLT tape drive as a TK50, I suppose it
> > would depend on the SCSI commands that a TK50 drive could handle and
> > how the driver is programmed. Anyone have a link to a TK50 manual
> > listing the SCSI commands?
>
> A TK50 is not a SCSI device, there has to be a controller between
> it and a SCSI bus, so it's a matter of what commands that controller
> implements.
Yeah, sure. Next you'll try to convince us that folk used wood and
plastic sticks for calculations before pocket computers and wrote
letters long hand before e-mail. :-)
Hmmm, so my system maps TK50 commands to SCSI commands and maps SCSI
messages to TK50 messages. Sounds painful but it appears to work
well. Is there a TK50 technical reference on-line somewhere?
Thanks, Bob, for the info.
AEF
Koehler) wrote:
> In article <e2be9987-84d3-4978-b973-3948b22be...@k9g2000vbl.googlegroups.com>, AEF <spamsink2...@yahoo.com> writes:
>
>
>
> > No problem. Withing 60 minutes they'll have come up with a cure and
> > you're good to go.
>
> Not if you're wearing a red shirt. Red shirts get the Republican
> plan.
LOL. That's good.
AEF