So to me that indicates that your clients are probably compressing the data.
Here are examples from some of my environments...
Volume Name Storage Device Estimated Pct Volume
Pool Name Class Name Capacity Util Status
(MB)
------------------------ ----------- ---------- --------- -----
--------
AAA025 PR3590 3590DEVC 9,262.5 100.0 Full
AAA031 3590P1 3590DEVC 9,150.4 100.0 Full
AAA042 PR3590 3590DEVC 9,170.1 100.0 Full
AAA049 3590P1 3590DEVC 9,194.0 100.0 Full
AAA055 3590P1 3590DEVC 9,080.6 100.0 Full
AAA063 3590P1 3590DEVC 9,142.9 100.0 Full
AAA066 3590P1 3590DEVC 9,210.3 100.0 Full
...
AAA143 3590P1 3590DEVC 15,914.5 95.7 Full
AAA455 10YRARCH 3590DEVC 40,000.0 2.8 Filling
AAB047 10YRARCH 3590DEVC 20,000.0 6.3 Filling
AAB078 3590P1 3590DEVC 10,240.0 43.5 Filling
AAB128 10YRARCH 3590DEVC 40,000.0 4.7 Filling
AAB152 3590P1 3590DEVC 10,240.0 11.9 Filling
AAB918 ARCHLOGTPEC 3590DEVC 10,240.0 72.3 Filling
AAC836 PR3590 3590DEVC 10,240.0 74.4 Filling
AAF275 3590P1 3590DEVC 22,485.5 100.0 Filling
AAF359 10YRARCHCP 3590DEVC 10,000.0 74.1 Filling
OK, now this might look odd but I'll explain where things come from
Used to I never assigned a "Est/Max Capacity (MB)" in my environments.
Back with older 3590 tape drivers, the driver estimated the capacity at
10,000MB as is seen with volume AAF359.
When new technology came out (and an associated driver, and remember newer
drivers support the older devices)
anyway, the default estimated capacity changed to 20,000MB as seen in volume
AAB047.
Once again, new stuff came out and new drivers were installed and the
default capacity changed to 40,000MB as seen in volume AAA455.
Now, since this environment was still the old 3590-B1A tape drives with old
"J" series tapes, the base capacity was still only 10 GB (aka 10,000MB).
Once I became tired of seeing all these 20,000MB's & 40,000MB's in an
enviroment that was actually 10,000MB I assigned a value of 10,240 MB to the
"Est/Max Capacity (MB)" for device class 3590DEVC (see volumes like AAB078).
Now, that estimated capacity value is assigned when a scratch volume becomes
private AND doesn't change until the volume either becomes full (see AAA143)
OR the amount of data written to it exceeds the estimated capacity (see
AAF275).
So with all this said, what I can say about the above tapes is...
Tapes like AAF359 were first written to back long ago (about 2 tape driver
levels ago).
Tapes like AAB047 were first written to back sort of long ago (about 1 tape
driver level ago).
Tapes like AAB128 were first written recently (on the current tape driver
level) but prior to me setting the "Est/Max Capacity (MB)" for the device
class 3590devc.
Tapes like AAC836 were first written very recently (on the current tape
driver level) after I got tired of seeing false information being reported
and set the "Est/Max Capacity (MB)" to 10,240 MB.
Tapes like AAA066 probably contain ONLY client data that was compressed at
the client... because when the tape drive attempts to compress the already
compressed data, it actually grows, thus these tapes don't hold their
reported 10 GB (because the 10 GB read from disk grows when written to tape
but the value reported by TSM is the amount that was pulled from disk to put
on the tape).
Tapes like AAA143 lets me know that 1 or more clients aren't doing as they
have been requested and are NOT using TSM client compression... because the
compression at the tape drive actually reduced its size. (and we know
already compressed data grows with attempted further compression)
Dwight
-----Original Message-----
From: Elio Vannelli [mailto:elio.vannelli_external AT WARTSILA DOT COM]
Sent: Tuesday, January 14, 2003 2:27 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Why my library doesn't compress data?
Thanks for your answer.
The problem is that TSM marks the tape as 10000MB while the tape is
FILLING. When the volume is FULL TSM says 6500MB. I don't have only
*.zip in my 250GB file server, but a lot of *.pdf, *.doc, images, CAD
files, ...
None of the 40 volumes marked as FULL reaches 7GB.
Thanks in advance
Elio Vannelli
|
