>Please summarise your answers to the net
O.K., and just in case anyone missed my original posting, I have included
it here first.
I feel that Rusty's response is most closely related to the problem I
found, and so I have included it in its entirety. If you wish to skip
directly to it, search forward for "6>" (leave out the quotes).
Thanks to all who responded, Don
> I have been watching this news-group for the last few days and haven't
> seen any info, so I am asking, although I am sure my problem must have
> been seen before.
>
> I spent the extra bucks to get the Exabyte 8500 so I could read and write
> both 2.3 and 5 Gigabyte 8mm tapes.
>
> Independant of which device-density I use (st1/9/17/25)
> - I can only write a little more that 2.1 GBs per tape.
> - mt reports status as Exabyte 8200
>
> I assume that
> - The drive needs rom upgrades,
> - The sun driver needs upgrades,
> - or I am doing something wrong.
>
> Please e-mail to show me the error of my/Exabyte's/Sun's ways.
> Thanks, Don
>
> Donald McLachlan e-mail don@mars.dgrc.doc.ca
and here are some of the responses I have received ...
***
Your drive is probably fine, although there's always newer firmware [...]
The Sun driver has it's problems, but since Sun doesn't officially support
the 8500, it's not really their fault. The Sun "mt stat" command will
claim that any 8mm or 4mm device is an EXB-8200.
I suspect what you're doing wrong is using tapes that were originally used
in an EXB-8200 in your 8500. When you load a cassette written in 8200
format, the 8500 switches automatically to 8200 mode and will write new
data on the tape in 8200 format for compatibility with older drives. To
get around this feature, you need to use new (blank) tapes in the drive,
Tape capacity also depends on tape length; to store 5GB you need to use a
112 meter cassette (e.g. Sony QG-112M). By way of comparison, the popular
Sony P6-120MP cassette is 106 meters long and holds just 4.6 GB.
X-From: Chris Maio <chris@boxhill.com>
***
I dont't know if this is the problem you have, but I noticed that I couldn't
write more than 2^31 bytes between an open and close of the tape device
(seems like an integer counter overflow), but otherwise there shouldn't
be any problem filling the tape with up to 4.5 GB.
Tommy Wallo Internet: tw@sics.se
***
Here's what I know from recent experience. The latest 8500 Firmware
revision is 03f2, which you need if you want 8200 compatibilty. The SUN
driver (under SunOS 4.1/4.1.1) does report that it finds a 8200, but it
should be using the 8500 format if you use a new or erased tape. If you
load a tape that has previously been written to with an 8200 the 8500
driver will switch to the 8200 mode for reads and writes, until a "clean"
tape is loaded. I use the Delta Microsystems driver, which allows you to
check which mode your in by reporting how much capacity is available (2.2G
for 8200 mode and 4.5G for the 8500 mode, w/ P120 tape.).
Doug Curtis
INET: curtisds@med.ge.com
***
>I assume that
> - The drive needs rom upgrades,
> - The sun driver needs upgrades,
> - or I am doing something wrong.
Probably 2). The problem is that the Sun SCSI tape driver doesn't know
that there are now 2 kinds of Exabytes; it only knows about the Exabyte
8200, and as such never sets the density of the drive, leaving it at the
default which may be low-density (I knew once, but forgot).
[this was followed by some info to configure the system to recognize the
Exabyte 8500, and the 8200 as separate devices. Since it hsa not been
tested by him, or by myself, I have excluded it.]
X-From: guy@auspex.com (Guy Harris)
***
Hello Don,
My name is Rusty Wilson. I'm a geophysicist/analyst with Amoco Production
Co. in Houston, TX.
Our oil/gas exploration groups have been using Sparc 1+/2 systems equipped
with Exabyte 8200/8500 8mm transports for some time now (since approx. Mar
1991 we have been using 8200's and have had several 8500 units since
Apr)...
I read your article (14061 of comp.sys.sun, Subject: Exabyte 8500 help
wanted) and felt compelled to reply to you directly.
We have experienced what I believe is exactly what you observe on your
systems. The device seems to fail after what seems to be an innocent
enough number of bytes transferred (we were initially writing variable
length records, so the significance of 2147483648 was NOT apparent at
first). We first believed that the SunOS 4.1.1 "st" driver for the SPARC 2
machines was not reflecting "end-of-media" conditions properly. After
further tests, however, it became obvious to us that the problem is REALLY
somewhere inside SunOS. The number 2147483648 is EXACTLY 2**31 (2
Gigabytes, counting in HEX). I am willing to bet money that the error you
are observing is (-1 returned from write(2), with an associated value 22
in "errno", see EINVAL in st(4s)...).
As you probably know, there is a 2G filesize limit for unix files. This
limit (I am told) has to do with inode structures in the 4.2 filesystem. I
understand that disk files inside of these file systems are limited to 2G,
but in my mind, there is NO reason that raw devices should have this limit
imposed.
We (AMOCO) have spoken to folks who "know" a little something about the
"sun4c st" device driver here in Houston, and they seem to think that
"st.o" may be counting bytes tranferred (God know why) and reporting the
seemingly unrelated EINVAL error when the u_offset device driver variable
goes negative.
At any rate, it is not possible to write(2) more that EXACTLY 2G to an
8200, or an 8500, for that matter (the SCSI st driver I mention in this
letter) is unaware of any distinction between the 2 device models. This
infers that the Sun SCSI driver is also incapable of doing SCSI-2 commands
used by the 8500 transport (MODE SELECT is an important one, it allows the
8500 to create tapes in either 8500 high density mode or 8200 low density
mode).
It also follows that as long as this problem persists in SunOS (kernal,
driver, or wherever), it will be impossible to write more than 2G on a
single tape (between open(2)/close(2) operations). If you have an
application that wants to:
{
open the unit,
write to till end-of-media condition is raised,
write tapemarks,
rewind (and possibly close)
} repeatedly
you will fail at 2 G. The vender for our application has a builtin counter
which keeps track of data transferred, and "simulates" end-of-media
processing when a customer defined threshold is reached (it stinks, but at
least we are running).
By the way, you should notice the same problem on 8200 devices with 112
meter tapes (2 hour). If you switch to a 90 minute tape (video tape), the
Sun SCSI driver WILL properly refect end-of-media to your program...
Also, if you have 8mm 8200 drives on a VMS based system (4/490, 4/360,
etc...) your tests should indicate an end-of-media condition after 261244
8K blocks are transferred. 2**31 bytes is exactly 262144 8K blocks. I
believe the SCSI driver on the larger systems is "counting" to avoid this
problem.
The downside of my long winded discussion is that with the current SunOS
SCSI driver, it is impossible to write more than 2G on a single tape,
regardless of whether it is an 8200 or 8500.
Rusty Wilson
email: rustyw@hou.amoco.com
***
By the way, I did know about the file size limitation, but of course one
never remembers these things, until someone prods him a bit.
Donald McLachlan e-mail don@mars.dgrc.doc.ca
Communications Researcg Centre / DRL tel 613-998-2845
3701 Carling Ave., fax 613-990-7987
P.O. Box 11490,
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:20 CDT