Recently, I've attached a Exabyte 8500c 8mm tape drive (actually the drive
is in an Exabyte 10e tape stacker unit) to a sparc 5 running solaris 2.3 and
AFS 3.3a. Initially, the sparc 5 complained about the Exabyte 8500c by
not recognizing it and issuing a "Fixed record length (1024 byte blocks)"
SCSI I/O error whenever the drive was accessed.
After checking with Sun, I determined that Solaris 2.3 has builtin support
for the Exabyte 8505 and 8500 but not the 8500c. I then found out from the
Exabyte Corporation that the problem could be solved by adding the following
entry to the /kernel/drv/st.conf file:
# Entry for the Exabyte EXB-8500C 8mm tape drive #
tape-config-list =
"EXABYTE EXB8500C", "Exabyte 8MM EXB8500C", "EXBT-8CC";
EXBT-8CC = 1,0x35,1024,0x0039,4,0x8c,0x15,0x90,0x14,3;
Well, this took care of the SCSI I/O errors. ufsdump and tar appeared to
access the drive as well.
However, when attempted to restore an AFS volume in our cell, I noticed
that over 8 hours was required to read EACH tape involved in the restoration,
which is entirely contradictory to the performance of either an Exabyte
8500 or 8505, in which case, only a few minutes was required to read each
tape. Unlike the Exabyte 8500c, the 8500 and 8505 were able to skip rapidly
through the tape and locate the file they were looking for very quickly.
Thy 8500c, on the other hand, was piggish and slow- perhaps it was only
reading one tape block at a time.
Anybody have any ideas about this? The default density mode for the Exabyte
8500c is 0x15 (compression mode), which is the same as that for the Exabyte
8505. The 8mm tape being read was produced on an Exabyte 8500 tape drive.
The device file I'm using on the 8500c is /dev/rmt/0n. I might experiment and
try /dev/rmt/0hn and some of the other available device files, though I doubt
this will correct the problem.
In case it matters, we're running the AFS 3.3 versions of butc, backup and
buserver in our AFS cell.
Hoping to get information about the settings for the Exabyte 8505, I called
Sun Tech support with no luck. I guess I'll have to bug the Exabyte folks
again.
Has anyone else experienced this anomaly?
Sincerely,
Steven McElwee
--
-----------------------------------------------------------------------------
Steven McElwee | Email --> | [EMAIL PROTECTED]
Academic Computing | <-- US Snail Mail |
Duke University |------------------------|---------------------------
401 North Building | (919) 660-6914 (Work) | (919) 684-8651 (Fax)
Durham, NC 27706 | | (919) 971-0781 (Cellular)
-----------------------------------------------------------------------------
