Is there a similar algorithm we can use to predict how many bytes of
     directory information are sent prior to incremental backup?  We are
     billing for I/O as well as storage . . . and are just starting to get
     questions about why our total I/O bill differs so much from the I/O
     reported in the backup log.  Is it safe to assume roughly that bytes
     backed up + directory comparison file size = total bytes I/O?  We are
     compressing on the client.

     Thanks for your help.  Eric Lewis  608-263-1652
     eric.lewis AT doit.wisc DOT du


______________________________ Reply Separator _________________________________
Subject: Re: ADSM database handling basics
Author:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> at IPNET
Date:    11/27/96 2:28 PM


>rule of thumb for sizing the database is that it should be between 1%
>and 5% of the total amount of space required for data storage.  We've
>got about 10,000,000 files that ADSM is tracking with about 800 GB in
>the storage pools (plus copy storage pools for everything) and our
>database is about 8 GB.

The size of an ADSM database does not depend on the amount of
storage pool space required, but rather on the number of files
stored.  The rule of thumb mentioned above is therefore very crude, at
best.  If you have an idea concerning the number of files to be stored,
following is a much better predictor of database size.

Every version of a file requires approximately 500-600 bytes of database
space.  Each additional copy of the file (i.e., cached copy or copy
in a copy storage pool), requires an additional 150-200 bytes of database
Additional database space will be required to allow for partially filled
pages and other overhead.

Dave Cannon
ADSM Development