At 08:28 AM 2/17/2000 -0500, Steven P Roder wrote:
>     My example was exaggerated, showing how collocation and maxscratch
>could harm you.  With 3570's, at 30 seconds/load-unload operation, you
>could be looking at 5 hours for just mounting the 600 tapes!  Now, if the
>library had DLT's in it, and if we estimate that it takes 4 minutes for
>one tape to unload, and the next to come ready (probably a low number in
>my experience), the Library would spend (4*600)/60 = 40 hours just
>mounting tapes!

We in fact have DLTs, and the way we address this is twofold.  First, we
have lots of DLT drive (8) and we run multiple migration processes
(migproc=3 or 4).  However, your point has validity to it.  The situation
we run into is that only 1 reclaim can run at a time, and I do have a
concern about whether the reclaim activity can keep up with the incoming
data.  Secondly, we have increased the amount of disk space fronting the
tape storage pools.  Since the collocation algorithm move largest filespace
first, this means that each subsequent filespace will be smaller and
smaller, with diminishing returns per tape mount.  Adding disk allows us to
cut back on the number of tape mounts somewhat.

I believe that collocation needs to be improved, but I am uncertain what a
requirement would look like.  I do know that we *require* collocation,
because the alternative of not using it would not work for us - restores
would take far too long.  I would think this would be a problem even with
non-DLT solutions, even though the mount waits would be shorter - at least
in large libraries.

If you do use collocation, as Steve points out, it is important to keep a
sufficient number of writeable empty or filling tapes, or else the
collocation algorithm will devolve into a non-collocated result.  We have
seen this happen as the capacity of our tape library is reached.

..Paul