From: Mike Broderick (broderic@MIT.EDU)
Date: Tue Jun 03 2003 - 18:36:46 EDT
The problem was I did not have an entry in the dynamic device
recognition database (/etc/ddr.db*) for my specific tape drives (QUANTUM
DLT7000). After adding them (edit /etc/ddr.dbase, then recompile with
ddr_config -c) compresion worked. Note: You cannot compile the db
once and push ddr.dbase/ddr.db to several systems (what I did first) as
ddr_config apparently updates the kernel too.
Why this worked before the upgrade but not after I'm not sure. My guess
is the desired compression values were incorrectly hardcoded somewhere
and that got "fixed" in the patch kit ...fixed for someone else, but
broke for me who was inadvertantly relying on them :-)
Thanks to all who replied (Alan Rollow, Dr Tom Blinn, Richard Loken,
Adametz Bluejay, Bouzianis Kostas)
Another interesting tidbits I learned is the device minor ID has a
compresion bit etc:
Tape: bbbbbbttttlllldddddr
Disk: bbbbbbttttllllpppppp
b - bus
t - target
l - lun
d - density
r - nowrewind
p - partition
But the catch is 'ls -l does not show the correct minor ID (a "cluster"
gotcha). Use 'ls -lD' to see a device minor ID that folows the above
convention.
_Mike
Mike Broderick wrote:
> Our DLT7000 tape drives (DLT IV tapes, attached to several systems via
> a SAN and in a StorageTek ATL) recently started filling up at half
> their [h/w] compressed capacity recently. (Netbackup kicks them out
> just before about 35GB.) It was first noticed on one tape and now all
> tapes are only taking 35GB (We specify the tapeN_d1 device). We see
> the same problem (out of tape) w/ a simple manual tar dump to tape of
> about 40GB. It seems like h/w compression is no longer happening. We
> manually loaded back on of the tapes and the compression light did not
> come on. We thought we saw a strong correlation to upgrading to pk4
> from pk3 but alas the one system still at pk3 also does not compress
> anymore either. We also backed down the drive f/w revs recently (to a
> version we use in another environment that compresses fine). We are
> checking w/ StorageTek for possible known issues with the firmware rev
> (but unlikely since it works for us elsewhere).
>
> I've seen hints to a bit in the minor device ID that indicates
> compression.
> What bit is this? Is there some way (e.g., mt status? ddr_config?) to
> query the device/drive from 5.1a and see if it is set for compression.
> I've looked at output from these two commands but am not sure what I'm
> looking for?
>
> _Mike
>
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:20 EDT