OK, here is how things run, based on my observations of putting 15
     terabytes to tape monthly...
     1) SCRATCH tapes, when pulled in and initially written on will show a
     capacity that A) is an estimate based on what ADSM knows of the
     device/media type B) what you told it to estimate for that
     device/media type.
     2) %occupied will be how much file space has been written to that
     tape.  That is, if a client has compression turned on and takes 10 GB
     of data and plops it on your diskpool as 5 GB then migration pulls it
     from disk and writes it to tape AND being compressed by the client the
     compression by a 3590 drive does nothing (stuffs already compressed) a
     3590 tape will show 50% used ie 5GB used of estimated 10 GB
     NOW another client sends 10 GB of uncompressed data to your diskpool
     and migration compresses it to 5 GB while putting it on tape... that
     same tape... and it fills it.  It will now read 100% FULL 15 GB of
     data, estimated capacity 15 GB  (if it has 15GB on it, its capacity
     must be 15 GB, right ?)
     3) NOW some files expire. NOT SWITCH TO INACTIVE... EXPIRE! An
     inactive file is an old version within the limit of versions you have
     specified for the policy set/domain, an EXPIRED in an inactive version
     that got rolled off the end into the bit bucket... Say half of each
     nodes data which would be 5GB each node BUT node#1 had already
     compressed its data so its 5GB's is really only 2.5GB to the ADSM
     server.  NODE#2's 5 GB is 5GB to the ADSM server.  The tape would look
     like: FULL, 7.5GB of data, 15GB capacity, 50% utilizied.
     The VALID DATA (whatever its specific name is in the listing) will
     refer to how much file space that data will occupy IN/ON YOUR DISKS !
     With all the compression that goes on at the different levels you
     could get in real trouble real fast BUT I feel ADSM does a real good
     job of letting you know the important number... which is WHAT IT MEANS
     IN YOUR ENVIRONMENT!
     This is where billing gets fun... if a client wants to chew up their
     own cpu cycles and compress their data before sending it to you they
     get a break (if you bill by the MB or GB) and if a client doesn't
     compress their data you get to make a little extra profit by billing
     them for technically more data then can technically fit on a 10GB 3590
     tape... I've got a lot of 3590's that are holding 60GB of file space
     on the client node... I've even have a SINGLE 3590 tape with 200+GB of
     user file space (an empty oracle DB, newly created and not loaded yet
     BUT you can bet that they are being charged for holding 200GB of space
     even though it only occupies a single 10GB 3590 tape GOD I LOVE IT)
     I know, I know, I'm evil ]:-)
     Hope this helps (you turn a little profit)
     later
          Dwight
                one of these days the bean counters will learn just to
     leave us alone and let us do our jobs....


______________________________ Reply Separator _________________________________
Subject: Re: Tape reclamation and one drive ????
Author:  ADSM-L at unix,mime/DD.RFC-822=ADSM-L AT VM.MARIST DOT EDU
Date:    2/25/97 12:57 PM


On Tue, 25 Feb 1997, Dwight E. Cook wrote:

|      Use "move data blahtapevolser stg=somediskstoragepool"  then it will
|      empty the tape to disk and return the tape to scratch status, if you
|      checked them in as status=scratch to begin with...

Interesting.  During that move, will ADSM move the entire contents, or
just the data that is active?  Many of my full volumes show the
utilization as low as 10%.  I'm using DLT4 tapes and really don't have the
resources to create a 20-40GB storage pool.  :)

_______________________________________________________________
Joe Morris  -  morris AT unc DOT edu  -  http://sunsite.unc.edu/morris
Academic Technology and Networks (formerly OIT), Development
University of North Carolina at Chapel Hill