Our backup disk storagepool is about 25 GB with a 1 GB file size limit,
which is enough to hold a days worth of backups.  The high threshold is
90%, low threshold is 5%, and caching is enabled.  We force the data to
migrate every morning by resetting the high threshold to 10% - this
kicks off 4 migration processes.  This way, with caching enabled, userrs
can still do restores from disk  My experience has been to try and avoid
migration when the backups are running as this can grind things to a
halt.  The high migration threshold should really depend on how big the
disk storagepool is and how much data and how fast you're throwing it at
ADSM   I've never run into any problems with having caching enabled but
did notice APAR PN76441 when I was applying the current ADSM maintenance
(2.1.07) - this is supposed to address some problems with disk caching..
here are the contents of the APAR ---

****************************************************************
:APAR.PN76441
****************************************************************
* USERS AFFECTED:                                              *
All ADSM Servers
****************************************************************
* PROBLEM DESCRIPTION:                                         *
During backup or archive to a disk storage pool with caching
enabled, a loop is executed and eventually broken out of with
the following message:

ANR9999D dfcreate.c(671):  Unable to free enough cache space,
skipping to next storage pool.

Another message that has been seen During backup/archive that
is related to this problem:

ANR9999D dferase.c(818):  Warning - bitfile (0,6145) not found
in DFCF.

During Restore/retrieve/export:
ANR0104E dfrtrv.c(1437):  Error 2 deleting row from table
"DF.CachedBitfiles".
****************************************************************
* RECOMMENDATION:                                              *
To eliminate this problem a DSMSERV AUDITDB DISKSTORAGE FIX=YES
must be run to clean up some invalid data base entries.  Turn
off disk caching until the fixing PTF can be applied.  Next
Issue MOVE DATA commands on the disk volumes specifying the
storage pool names that the disk already reside in.  This will
not move any data, but it will delete cached files.  When the
fixing PTF is applied, update the storage pool to turn disk
caching back on.
****************************************************************
Inconsistent entries related to disk storage pool caching were
being put into the ADSM database.  A DSMSERV AUDITDB
DISKSTORAGE FIX=YES must be run to clean up the invalid
entries.
The APAR fix will eliminate this inconsistency from happening
in the future.


Tim Pittson
tpittson AT himail.hcc DOT com

>----------
>From:  Richard Sims[SMTP:rbs AT ACS.BU DOT EDU]
>Sent:  Friday, May 10, 1996 10:22 AM
>To:    Multiple recipients of list ADSM-L
>Subject:       Re: Migration process never appeared to start again
>
>>I am wondering though, the %util on the disk storage pool is hovering right
>>arount 100% while this bkup is occuring.  And its seems to come down a
>>few fractions of a percent while the %migrated seems to go up roughly
>>the same amount.  I have file caching on on the disk pool, but does
>>ADSM only free up disk space occupied by cached files on a as needed
>>basis????
>
>My experience thus far shows that ADSM Caching is problematic: it keeps
>the
>storage pool capacity up around 100%, but doesn't react fast enough to
>reclaim space when it's needed.  I had an HSM-controlled file system
>NFS-exported to another AIX system in order to copy data.  Caching was
>on
>and I kept the high migration threshhold under 50%.  Data copying
>failed
>on "remote file system full", "No space left on device".  I turned off
>Caching and copying succeeded.
>    Can others with longer-term experience with Caching lend any
>insights
>or advisories on configuration which may make Caching work; or should
>one
>simply stick with 90% high migration values to have a caching effect
>but
>maintain a space margin?
>      thanks, Richard Sims, Boston University OIT
>