Summary: Exabyte M2 Compression problem

The compression problem I had experienced with an Exabyte M2
drive was a tape drive hardware problem.  Upgrading firmware
from v05c to v07g didn't correct the problem. I swapped the bad
drive out with another borrowed M2 and the ufsdumps are now
back on a single tape.

Thanks to the following individuals:
Andrew Watkins
Steudten Thomas
Luc Suryo
Reginald Beavers
Edward James
Peter Stokes

Lessons learned:
1) LED display will show a '+' during usage if h/w compression is in use
2) Using a larger block size with ufsdump allows more efficient
   tape usage

Tom Jones

------------ Original post: ------------
I'm having a problem with compression on an Mammoth2
tape drive (firmware v05c) connected to an
Enterprise E420R running Solaris 2.6

ufsdump has recently started hitting EOT and requesting
a 2nd tape to be inserted.  The largest filesystem being
backed up to that tape is just over 65GB containing user's
mailboxes (i.e. text files - should be good compression)
The native capacity of the M2 drive is 60GB so I should not
be hitting EOT at 65GB.

The st.conf setting is set to the Exabyte recommended
setting:

"EXABYTE Mammoth2", "Exabyte Mammoth2", "EXB-M2";
EXB-M2 = 1,0x35,0,0x1de39,1,0x28,0;

The ufsdump command I'm using (inside a shell script) is:
ufsdump 0ubf 512 /dev/rmt/0n /dev/md/rdsk/d13

Has anyone seen this compression problem before?  Anyone
with different st.conf settings?  I found a webpage with
test comparison results between DLT and M2 that had
a minor difference in the st.conf setting.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers