exabyte errors
Lisa Amedeo
amedeo at DCDLAA.FNAL.GOV
Tue Apr 9 00:31:47 AEST 1991
Mark Bartlet writes:
Finally, question #3. Does anyone have a clue as to what's going on here?
% maketape /dev/rmt/tps0d7nsv # "nsv" device works fine
5+0 records in
5+0 records out
10+0 records in
10+0 records out
15+0 records in
15+0 records out
%
% maketape /dev/rmt/tps0d7ns # "ns" device doesn't
5+0 records in
5+0 records out
dd: write error: I/O error
3+0 records in
3+0 records out
dd: write error: I/O error
3+0 records in
3+0 records out
%
I think the problem lies in the fact that Mark has changed devices
from variable to fixed (i.e. tps0d7nsv to tps0d7ns).
After much investigation by serveral people at FERMI and at SGI, it
turns out that in 3.3.1 and 3.3.2 of IRIX, there is a problem that
occurs when moving between the variable length 8mm device ( tps*v)
and the fixed devices. The problem is as follows: upon bootup,
all devices work as they should and each device has a default block
size variable set. The fixed device block size should be 1024.
Now lets say you use a variable device for *any* command that accesses
the tape drive (this includes mt). The correct default block size is
set and things work fine until you try to switch back to the fixed
device. The move from variable to fixed resets the block size and now
the fixed device has a block size of one (1). Remember it should be
1024. Meaning, when you try to write to the tape, the tape protocol
looks at the default block size and says that one byte of data will
be written to a 1024 byte block. Then the rest of the block will
be filled with filler. Technically this should work, even if it does
take forever, however the exabyte drive times out.
The only way to fix this problem is to reboot the system or compile
the program below and run it prior to any usage of a fixed device.
This program was given to us by SGI reps working on this issue.
I believe this problem is seperate from the scsi failures others have
seen. I have also seen the scsi errors in SYSLOG since upgrading to
3.3.2 and the errors have occured on systems that are using the
8mm variable device exclusively. On one of the systems with the
scsi failures, I shutdown, reseated all connectors then came back up.
The scsi failures have not been recorded since then ( about two weeks
ago ).
Hope this solves some of the exabyte trouble others have been having!
And by the way, SGI says the fixed block size problem will be gone in
4.0 of IRIX.
Lisa Amedeo
UNIX System Administrator
FERMI National Accelerator Laboratory
Batavia, Illinois
(708) 840-8023
e-mail: amedeo at dcdlaa.fnal.gov
-------%<---------------%<-----------------%<------------------%<--------------
/* C program to fix the 8mm exabyte fixed device block size. */
/* This program is duplicated here exactly as it was given to us by */
/* SGI technical REPS. Note that the program hard codes the tape */
/* device in as /dev/tape. By SGI default, /dev/tape accesses tape */
/* device /dev/mt/tps0d2. If you are using a different device you */
/* will need to change the appropriate line in the code. */
#include <sys/types.h>
#include <sys/mtio.h>
#include <stdio.h>
main()
{
struct mtop mtop;
int fd;
if((fd=open("/dev/tape", 0)) == -1) {
perror("tape open failed");
exit(1);
}
mtop.mt_op = MTSCSI_SETFIXED;
mtop.mt_count = 1024; /* exabyte default fixed block size */
if (ioctl(fd, MTSPECOP, &mtop) < 0) {
fprintf(stderr, "setblksize ioctl on %s ");
perror("failed");
exit(2);
}
exit(0);
}
More information about the Comp.sys.sgi
mailing list