> 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)
> -----------------------------------------------------------------------------
Here's betting that you have a large number of volumes stored on that
tape ( > 500 ). We started putting our users home spaces in AFS and
noticed that our user restores would take an incredible amount of time
to scan the tapes. There's a configuration entry for SCSI tape drives
that indicates whether or not the drive can sense End-of-tape or not.
By default (at least on SunOS 4.1.3 systems) this flag is false. This
forces any fast-forward commands to step through file-mark by
file-mark instead of streaming to the correct spot. On 4.1.3, the
following change needed to be made sys/scsi/targets/st_conf.c to
indicate that the tape drive supported the End-of-tape sense. (I've
been told that all Exabyte drives do.) I assume there's a similar
flag for Solaris 2.3 although I don't know what it is.
/* Exabyte 8mm 5GB cartridge */
{
"Exabyte EXB-8500 8mm Helical Scan", 16, "EXABYTE EXB-8500",
ST_TYPE_EXB8500, 1024,
(ST_VARIABLE | ST_BSF | ST_BSR | ST_LONG_ERASE | ST_KNOWS_EOD),
5000, 5000,
{ 0x14, 0x00, 0x8C, 0x8C },
{ 0, 0, 0, 0 }
}
The "ST_KNOWS_EOD" variable above was added to the existing entry.
Kevin Hildebrand
University of Maryland, College Park
Project Glue Systems Developer
