SUMMARY: DLT7000 question

Thanks to: tom, oneil, bernard mcauley, Larry Gardner, Jay Lessert, and
Nelson Caparroso.

The original question:
> Hello,
> I have a dlt7000 drive on a solaris 8 box, using DLT-IV tapes.  For some
> reason I am only getting 32gb to 37gb on each tape.  From the LEDs on the
> drive, It is set to 35gb, and compression is enabled.  I have tried using both
> /dev/rmt/1c and /dev/rmt/1u devices. but I cant pack anymore stuff on these
> tapes. I am dumping normal files, When I have dumped this data on to 8mm
> tapes. I got 25% to 50% compression, so I would expect the same here. (same
> filesystems, getting 7gb to 9gb on 160m 8mm tapes) This is a sun branded
> dlt7000 drive.
> My st.conf entry:
> 
>         "QUANTUM        DLT7000",       "Quantum DLT7000",      "DLT7k-data",
>         "SUN    DLT7000",       "Sun DLT7000",  "DLT7k-data",
> DLT7k-data =    1,0x38,0,0xD639,4,0x82,0x83,0x84,0x85,2;
> 
> The questions I have are:
> 
> 1. How can I be sure that hardware compression is happening. if the LED is
> lit on the drive, is it compressing?
> 2. I do not know what the tapes have been used on in the past. I have DD'd
> over the first 10 blocks of the tape to wipe any data off, should that
> take care of any problems with the drive thinking it is a dlt4000 tape?
> 
> 3. any other ideas why these tapes are not holding data in the 55gb to 70gb
> range? 
> 
> 

The email's back:

Tom stated that it looks like I might be using double compression. I looked
in to this a bit, looks like it was only the drive using compression.

bernard mentioned that it could be a patch issue, I did find a DLT7000
firmware patch (thanks for the idea bernard) and my firmware was older. so
I applied the new firmware.  Well, the drive still works :-).  I still am
getting somewhat poor compression.  at this point I am thinking it is just
the filesystem.

Larry and Nelson sent me some st.conf entries:
   DLT7k-data =    1,0x38,0,0x1D639,4,0x82,0x83,0x84,0x85,2;
   DLT7k-data =    1,0x38,0,0x1D639,4,0x82,0x83,0x84,0x85,3;  

Mine is currently:
   #DLT7k-data =   1,0x38,0,0xD639,4,0x82,0x83,0x84,0x85,2;

I will try both of these later this afternoon. Larry also mentioned that
35 to 37gb is not that abnormal for binary data (which this is).

Jay sent me a real cool idea (and script) as to how to verify drive
compression is working.  This is so obvious, i cant believe I did not think of
it. Below is Jay's script:

       #!/bin/sh
    cd /var/tmp
    mkdir testdir
    mkfile -v 1000m testdir/file0
    mt -f /dev/rmt/1hn rewind
    failed=0
    until [ "$failed" = "1" ] ; do
        time tar cbf 126 /dev/rmt/1hn testdir || failed=1
    done
    mt -f /dev/rmt/1hn status

    mt -f /dev/rmt/1un rewind
    failed=0
    until [ "$failed" = "1" ] ; do
        time tar cbf 126 /dev/rmt/1un testdir || failed=1
    done
    mt -f /dev/rmt/1un status

This script does two things:
1. a file of zero's should compress very well. so you should be able to pack
allot more 1gb files on the tape when using hardware compression than when
not.
2. the drive does take in data faster when using hardware compression (and
that compression is doing something) so the tars should go faster.

both of these where true.
All in all, it looks like I just have data that does not compress well,
jays idea shows the drive is 100% functional.

Thanks!

 -Mike Ekholm

-- 
UNIX Sys Admin | ekholm_at_ekholm.org | http://www.ekholm.org | IRC: Nalez
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    "It's hard to find people in society who can administer UNIX
     and professionally carry a weapon."
       - Jim Williams, former FBI Computer Intrusion Squad agent
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers