SUMMARY: Glacial ufsrestore from 8mm tape

  Well, after a HUGE amount of go-round with Sun the conclusion, which
totally amazes me, is that this is within normal tolerances for Exabyte
Mammoth drives.  This quoted from Exabyte themselves by Sun.

  A bit more info than the original message:  Turns out that the
problem has to do with cross-compatibility of tapes written on different
drives.  I.e. the one drive we use to write most of our tapes (drive A)
writes tapes that are not 'easily' read by the other drive on that system
(Drive B).  BUT... they ARE readable on another drive on, as it turns
out, my workstation.  And if we try writing on drive B we get that it
doesn't read well on either A or my workstation.  And various other
combos with other drives in the shop here.

  In going over this with Sun I made up a matrix of which drives would
read which other drive's tapes and it was amazing...  And it does seem
to actually do a reposition or search when it is having problems with 
a tape - I could actually see it on the L400 display of drive status.
That explains the time it takes - all that repositioning is time
spent at 0 transfer rate.

  It was fun trying to get them to actually understand what I was saying
and then the couple/three different replacement drives some of which did
exactly the same thing(!).  We even got a firmware upgrade to them to
see if that would help.

  Finally, Exabyte told them it was normal(!).  Bottom line is, we'll be
sure to, if at all possible, read tapes on the drive that created them.

  Original message follows:

----------

From: bob@dtcc.edu (Bob Rahe)
To: sunmanagers@sunmanagers.org
Subject: Glacial ufsrestore from 8mm tape

  Well, this drove me nuts.  Does anyone know what might be going on to
cause these symptoms and how to fix it?

   System is an E6500, 14x400Mhzx14G with two Exabyte 8900 (Mammoth)
8mm tape drives.  Solaris 8.

   The problem is that a ufsrestore of files from backup tapes can take
a HUGE amount of time.  Case in point - last nite, tried to restore a
directory containing approximately 125 Megabytes in approximately 1200
files.  Restoring into the /tmp directory ('swap' in the df listing).

  This is a multi-file tape, the filesystem that we needed to recover
the directory from was the second file on the tape so an mt command
with fsf 1 was used on the no-rewind device and then an interactive
ufsrestore (blocking of 480) to select the directory.  The ufsdump
(with a block specified as 480) of this file system (approximately 10G)
took about 50 minutes.  The restore of just the direcory took
over 4.5 HOURS!

  Now I could see it taking 50 minutes but this was ridiculous.  And
not the first time we've seen this kind of thing altho this was
definitely the worst.

  One other point I might mention: I happened to be in the room where
the tape is situated and it sounded like the tape was in high-speed
search/motion at least twice during the restore.  For whatever THAT
might mean....

  Thanks and I'll summarize.

Bob


-- 
----------------------------------------------------------------------------
|Bob Rahe, Delaware Tech&Comm Coll. /                                      |
|Computer Center, Dover, Delaware /                                        |
|Internet: bob@dtcc.edu  (RWR50) /                                         |
----------------------------------------------------------------------------
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers