ADSM-L

Collocation Concern

2015-10-04 18:16:47
Subject: Collocation Concern
From: INTERNET.OWNERAD at SNADGATE
To: Jerry Lawson at TISDMAIL
Date: 2/9/96 4:46PM
Thanks for the information - Your explaination was very clear.  My apprehensio
ns are not from the design, but rather the result of our changing direction
when we have a large number (280) of "filling" tapes.  I have visions of the
first migrations after we turn colocation off having many extra mounts because
these tapes are close to being full.

We have rationalized the change in philosophy something like this - We liked t
he idea of having a minimum number of tapes for a client, but can't live with
a couple of thousand partly full tapes in the automated library.  Since ADSM m
igrates data from one pool to the next based on who is the largest user, we be
lieve that a user will tend to stay in the DASD pool for a while, and then all
of his files will be moved together.  The result of this (with colocation off)
will be (as a rule) a group of files together for a user, and then another
cluster on another tape (or tapes), etc. This is not as ideal as collocation,
but certainly is not the end of the world.  Of course tape reclamations may
frament the user's files more, but the world is not perfect.  The one thing I
did not consider was the use of the "filling" tapes.  Initially, this might
spread a users files over several tapes when they might have fit on one new
scratch tape.

I am probably being paranoid about this.

One aside - we have created a separate DASD pool now for servers.  We feel tha
t since the amount of data that they backup each day is relatively large, comp
ared to a desktop machine, they will still benefit from collocation.  This is
because if they were in a pool with desktop machines, they might migrate every
day or so.  If they were not co-located, their data could be spread over an ex
tremely large number of tapes.  The relatively low number of servers (in compa
rison to desktop machines)  makes this tradeoff seem worthwhile.

Jerry Lawson




________________________Forward Header________________________
Author: INTERNET.OWNERAD
Subject: Collocation Concern
02-09-96 04:46 PM

Jerry Lawson writes

>We have been using collocation for our desktop machine backups, but the
>rapidly expanding number of customers has pointed out to us how wasteful this
>is in our silos.  Therefore, we have decided to turn it off.  In reading the
>Admin GUIDE, the implication was that when I turned off collocation, all of
>the existing volumes in the storage pool that were in "filling" status would
>now be used to satisfy storage needs during the next migration.  Is this
>correct?  In other words - when I run the next migration - ADSM will start to
>mount already allocated tapes that have not been filled up, and continue to d
o
>this until all of the preallocated tapes are filled, and then it will as for
>a new scratch mount.

>Am I reading this correctly?

Once you turn off collocation, tape selection will be based on the
algorithm for non-collocated storage pools.  The server will try to
select the most full volume that is in filling state.  However, if
a file must span to a second volume, the server will attempt to use
an empty tape for the spanned-to volume; this is done to minimize
the chance that a third tape will be required for this file.
The volumes that are currently in filling state will eventually be
filled, and you should be left with a small number of filling
filling volumes.

>I am a little concerned about this, because it would seem that for a while,
>migrations will ask for lots of tape mounts until the pool is full.

I don't understand the concern.  Migration will probably require fewer
volume mounts, since it will not be necessary to mount a new tape
for every node.  In general, each migration process will require only
a single output tape at any given time.

Dave Cannon
ADSM Development
<Prev in Thread] Current Thread [Next in Thread>