Thanks for the info Steven.  Based on what we are seeing, I'd say that's
incredible!  Particularly the 019A11 tape.  Maybe I have a different
problem.  All of the tapes I have, including those that are scratch, have
been written in the 3570 uncompressed format.  Now that I have changed
the devclass to 3570 compressed, do I need to reinitialize the tapes that
were previously written to as uncompressed?  I have been told by two
other sources that I would not have to do anything to the tapes to get
them to record in compressed format other than make sure they're scratch
when they get written.  Any ideas?  Shaun

 -----Original Message-----
From: Steven P Roder
Sent: Monday, June 21, 1999 3:05 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: 3570 Compression

> We don't use client compression at all.  Rely entirely on the drives
for
> compression.

We also do not use client compression, but some of our "customers" store
compress files.  Here are my stats for mostly unix clients (Solaris, SGI,
AIX_, and about a dozen NT Servers:

Average data on All  3570 tapes (MB/tapes) = 21415626.7/1425 =
  15028.51MB
Average data on Full 3570 tapes (MB/tapes) = 20855129.6/1363   =
15300.90MB
Average data on Vaulted 3570 tapes (MB/tapes) = 11539106.2/746 =
15467.97MB
Average data on non-DEPT 3570 tapes (MB/tapes) = 8657613.3/570 =
15188.79MB
Average data on Primary  DEPT tapes (MB/tapes) = 1218907.2/109 =
11182.63MB
Average % in use of Full 3570 tapes                            =  52.99%

Tape with least data:
249203 DEPT_TAPE    3570DEPT      6,178.1   27.0    Full

Tape with most  data:
019A11 BACKTAPE     3570TAPE     55,072.9   48.6    Ful

I get less compression on the "DEPT" tapes because those are personal
desktop machines, not servers, and those users tend to tar-n-compress
stuff to save disk space.

019A11 most likely has an Oracle database on it.

Steve (unVMix Systems Programmer/Dude) Roder
(tkssteve AT ubvm.cc.buffalo DOT edu | tkssteve AT acsu.buffalo DOT edu | 
(716)645-3564
,
   | http://ubvm.cc.buffalo.edu/~tkssteve)