MY question concerned a full dump of a 8GB file system on an
AS 2100 running newly upgraded (from 3.2b) 3.2g to a tlz06
eg
<snip>
So far(under 3.2b) things have been fine. Now however(just when I need to
depend on the dump) the dumps are failing.
On the second volume of the three volume dump the dump failed with
a media error. The system could not eject the tape, and the device
(/dev/rmt0h) was blocked. "mt status" gave a CAM error.
This was only the second time the particular tape had been used.
A reboot partially fixed the problem, I was able to eject the tape,
and do an "mt status" without misshap. I interupted another "mt status"
(cntrl-c) and then the device blocked again. Further examination just gave
CAM errors.
I swapped the tape drive out for an almost unused tlz07 that was in an
alphastation upstairs, recompiled the kernel etc, booted to single user
mode and tried again(I didn't remake the device files(eg MAKEDEV tz) should I
have?); the tape was new. Failure again.
The following is typical of the CAM errors I get.
vmunix: cam_logger: CAM_ERROR packet
vmunix: cam_logger: bus 0 target 5 lun 0
vmunix: ss_device_reset_done
vmunix: Bus device reset has been performed
vmunix: cam_logger: CAM_ERROR packet
vmunix: cam_logger: bus 0 target 5 lun 0
vmunix: ctape_iodone
vmunix: Hard Error Detected
vmunix: DEC TLZ06
vmunix: Active CCB at time of error
vmunix: CCB request completed with an error
vmunix: Error, exception, or abnormal condition
vmunix: MEDIUM ERROR - Nonrecoverable medium error
If its a medium error then why the Bus device reset on boot,
and how come its happening with new tapes?
What do you think, have I just got a bad batch of tapes?
(new ones are on order) if so it doesn't say much for
DAT tape reliability.
I'd REALLY appreciate your thoughts on this.
------------------------------------------------------------
responses;
>From mcrowley_at_mhc.mtholyoke.edu Sun Feb 9 02:56:57 1997
Subject: Re: Tape errors
Not that this helps your current problems, but I have been very
happy using tz86, tz87, and tz88 tape drives.
6/- 15/30 20/40 Gig normal/compressed
Tape type:
compaq III III IV
US$ 45 45 100
I was using a tlz04 dat drive with digital tapes. While I didn't
have any problem with tape reliability on that drive, one of
my collegues did have problems with another non-DEC DAT drive.
Finally, however, my tlz04 stopped ejecting the tapes properly.
It ended it's life with a tape jammed in it with no easy way
of extracting it. (And we are not mechanical idiots.) So it
just sits there. The TZ88 I recently clocked at doing a vdump
at about .89Gig in 6 min. Time and reliability can make these things
pay for themselves, if you have the capital. You might try to find
a used tz87, given the size of your array.
With the tlz04 (1Gig tape, no compression), I used these parameters for
dumping. I was never quite sure whether it correctly found the end
of tape or not, but I believe it did and I believe these entries just
caused it to run as far as it could.
# Tape information
Size=10000
Density=100000
dump ${Level}usdf ${Size} ${Density} ${nTapeDev}
For CAM errors, if you can find shorter SCSI cables, that might help.
---------------------------------------------------------------------
Michael A. Crowley mcrowley_at_mtholyoke.edu
Director of Network and Technical Services 413-538-2140
Mount Holyoke College, Dwight Hall fax: 413-538-2331
50 College St, South Hadley, MA 01075
---------------------------------------------------------------------
>From nschelle_at_crosskeys.com Tue Feb 11 06:54:47 1997
Subject: Tape errors
Hi Brian,
I'm in an enormous rush (Monday, eh?) but I thought I'd drop you a quick
line. I'd associate both of these groups of errors with SCSI bus length
and/or termination problems. Perhaps you're just over the length limit?
I realise that you said that things have been working fine, but these
are exactly the sort of errors that I got when we were just over length
limit (only by about 10cm as it turned out). The errors were
intermittent: sometimes things worked fine and sometimes the bus hurled.
vmunix: cam_logger: CAM_ERROR packet
vmunix: cam_logger: bus 0 target 5 lun 0
vmunix: ss_device_reset_done
vmunix: Bus device reset has been performed
vmunix: cam_logger: CAM_ERROR packet
vmunix: cam_logger: bus 0 target 5 lun 0
vmunix: ctape_iodone
vmunix: Hard Error Detected
vmunix: DEC TLZ06
vmunix: Active CCB at time of error
vmunix: CCB request completed with an error
vmunix: Error, exception, or abnormal condition
vmunix: MEDIUM ERROR - Nonrecoverable medium error
Sorry for the brevity but it sounds like you know one end of an active
terminator from the other already anyway.... ;-)
Regards,
Neil
--
Neil Schellenberger | Voice : (604) 205-9900 ext. 5922
CrossKeys Systems Corp. (West) | Fax : (604) 205-9940
#502 - 4180 Lougheed Highway | E-Mail: neil.schellenberger_at_crosskeys.com
Burnaby, B.C., Canada, V5C 6A7 | URL : http://www.crosskeys.com/
... DYB ...
------------------------------------------------------------
/usr/field/tapex -E -o tapeex.out
completed with no errors, and yesterday a full dump in multiuser mode
(useless I know, but ok for testing) completed with no errors.
So I'm stumped.
All the devices are internal, so cable LENGTH may not be a problem,
but may be we have a bad cable/connector somewhere.
What about dump? this is the first time I have used dump with
3.2g, could there be a bug(ok with small file systems, not with large)?
Does dump need something that single user mode isn't giving eg(running the
update daemon)
<sigh> I dream of DLT's and 1 tape backups
frustrated
boc
--
------------------------------------------------------------
Brian O'Connor, Unix Systems Consultant
Latrobe University,Bendigo
boc_at_ironbark.bendigo.latrobe.edu.au
------------------------------------------------------------
Received on Tue Feb 11 1997 - 00:23:24 NZDT