We saw a problem with caching when running SQL-Backtrack backups using the
API.  Apparently, backtrack sends an object size estimate to ADSM and when
the object comes back larger, the alloc fails because ADSM has reserved X
blocks and will not release the rest.  Prior to more current versions, this
crashed the server.  Now you should just see internal server error
messages.

David Hendrix
dmhendri AT fedex DOT com

>Tom,
>        Having cache enabled for your disk storagepools does take up some
>additional Database space.  I also seem to remember some problems with
>having cache enabled but I'm pretty sure they've been fixed by
>subsequent maintenance levels.  Only reasons I can think of for not
>enabling cache is that your users don't do too many restores or your
>disk storagepools are small and the data only stays out there for a very
>short period of time (less than a day).

>Tim Pittson
>tpittson AT himail.hcc DOT com

>----------
>From:  Tom Denier SMTP:tom AT STAFF.UDC.UPENN DOT EDU!
>Sent:  Friday, August 23, 1996 2:47 PM
>To:    Multiple recipients of list ADSM-L
>Subject:       Caching migrated files
>
>By default, disk storage pools are defined with caching of migrated
>files
>enabled. This means that files migrated to tape are not deleted from
>the
>disk storage pool until the space they occupy is needed to accomodate
>newly arrived files. If a client requests a restore of a cached file
>the restore can be done with no tape mount. I recently inherited
>responsibility for an ADSM server whose disk storage pools have
>caching of migrated files disabled. Is there any conceivable reason
>why I would not want to enable caching for these storage pools?
>