This note is about the collocation option of ADSM on large servers.

If I understand the "problem" with collocation correctly, it is that on
ADSM servers with large numbers of non-Full tape volumes, a Migration
process will tend to spread the data out across all available (non-full)
tape volumes.  This will tend to mount all tapes that are not full.
Is this analysis of the "collocation problem" correct?

Anyway, it seems to me that if this is the problem, that enhancing the
collocation code (invoked during migration) might be a reasonable way to
address this problem.  Right now (if my guess is right), collocation will
tend to spread data across as many tapes as are available, to maximize the
likelihood that all data for a node is on as few tapes as possible.  While
this minimizes the number of tape mounts needed for a full-node restore, the
side-effect of this is too many tape mounts during migration.

I can see two possible ways that "collocated migration" might be enhanced
to address this problem:

1) Limit the degree to which "collocated migration" spreads node data
   across tapes.  Instead of spreading it across all available tapes,
   provide a way that the ADSM administrator could limit the spreading
   function.  For example, in a library with 1000 tapes, you might specify
   that ADSM have a goal of having no more than 50 tapes in "Filling"
   status.  The other 950 tapes would either be in "Full" status or "Empty"
   status.  As a tape filled up, an "Empty" tape would be put into service.
   It seems to me that this might provide a way to balance the goal of not
   having too many tape mounts during migration, and not having too many
   tape mounts during a full-node-restore.  This would increase the number
   of tapes that one node's data is on, but not nearly to the degree that
   turning collocation off would do so.  On the other hand, it would tend
   to limit the number of tape mounts needed during migration.

2) Right now, I believe that migration picks the node, or filespace, that
   has the most amount of data on disk, to move to tape first.  Then the
   next largest, etc, etc.  If instead of doing this, migration were able to
   select the fewest number of tape mounts to satisfy the amount of data that
   needed to be migrated to tape, this would lower the number of tape mounts.
   I don't think this would increase the number of tapes that a node's data
   was on, but it might to some degree.  Certainly, the node's data on tape
   would probably be more fragmented within the tape, but I don't think that
   will create any problems.

   Question for IBM:  Does the "collocation migration" algorithm make any
   attempt to minimize tape mounts right now?

I haven't thought these ideas through.  However, I am concerned that larger
sites feel that collocation is not an option for them.  It would seem to me
that a useable collocation alorithm is >most< needed in larger sites, and
I'd like to see if collocation could be made viable for them (>before< we
become one of them).

..Paul

Paul Zarnowski                     Phone:   607/255-4757
Cornell Information Technologies   Fax:     607/255-6523
Cornell University                 US Mail: 315 CCC, Ithaca, NY 14853-2601