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:[EMAIL PROTECTED]] Sent: Tuesday, January 14, 2003 2:27 AM To: [EMAIL PROTECTED] 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