Summary: Exabyte M2 Compression problem

From: Tom Jones <>
Date: Fri Sep 20 2002 - 11:08:08 EDT
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

"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
Received on Fri Sep 20 11:15:39 2002

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:55 EST