ADSM-L

Re: On minimizing client HD restore time

1996-11-13 19:34:44
Subject: Re: On minimizing client HD restore time
From: Paul Zarnowski <VKM AT CORNELLC.CIT.CORNELL DOT EDU>
Date: Wed, 13 Nov 1996 19:34:44 EST
On Wed, 13 Nov 1996 15:37:03 -0500 Wayne T. Smith said:
>I think we'd really like to be able to treat "active" files differently
>from "inactive" files to keep volume restore times to a minimum.
>Anyone doing anything in this area?  IBM?

Wayne,

I have also been thinking about how we could improve on ADSM's standard
reclaim logic.  We are now using DLT tapes which have a capacity of 20GB
and reclaims for these tapes usually take days.  This causes us problems,
because when a reclaim is running, backups slow down, migrations slow down,
expirations slow down, etc.

1) We would really like to limit reclaim activity to certain hours of the
   day.  We currently try to do expirations during the morning, and
   migrations during the afternoon, to limit overlaps.  With multi-day
   reclaims, we can't control overlaps as well.

I also suspect that a rather large percentage of the files that hit tape
do not last very long before they get expired.  This bothers me, as this
will cause more reclaim activity and/or lower tape utilization.  I would
like to figure out some way to address this issue.

2) I have thought about doing MOVE DATAs from tapes which would normally
   be eligible for reclaim, but instead of moving to tape volumes in the
   same storage pool, instead moving the data to tapes in a different
   storage pool that did not have collocation turned on.  My belief is that
   a MOVE DATA to a non-collocated storage pool will be much faster than a
   RECLAIM (or MOVE DATA) to a collocated storage pool.  This is because
   substantial processing must be done by ADSM when moving data to a
   collocated storage pool, but not when moving to a non-collocated pool.
   What I would really like to do, is to MOVE DATA from the dying tape onto
   another (mostly empty) tape in the same storage pool, but without
   invoking the collocation logic.  At least, I think I want that.

I suppose it might just be time to get a faster server.

If we could improve our database i/o performance, that would provide us
the best overall solution.

..Paul

Paul Zarnowski                     Phone:   607/255-4757
Cornell Information Technologies   Fax:     607/255-6523
Cornell University                 US Mail: 315 CCC, Ithaca, NY 14853-2601
<Prev in Thread] Current Thread [Next in Thread>