ADSM-L

[no subject]

2015-10-04 17:33:43
> At 11:21 AM 2/16/2000 -0500, you wrote:
> >maxscratch of 320 here would be way uncool.  Can you imagine =
mounting
> >nearly all of these tapes everyday for migration, and then again for
> >backup storage pool?!  600-some-odd mounts!
>
> That's what robots are good for.  The alternative of mounting =
potentially
> dozens of tapes for a restore is even less attractive, IMHO.  If you =
have
a
> sufficiently large disk storage pool in front of your tape storage =
pool,
> this will reduce the number of required tape mounts, assuming that =
you
> don't migrate the disk stgpool all the way down to 0%.

     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 =3D 40 hours just
mounting tapes!
     I think in these cases, one has to manually manage the maxscratch
value, keeping some number of filling tapes at all times.  And as the
number of filling tapes decreases, if maxscratch has been reached, your
tapepool begin to resemble a non-collocated pool.
     IMHO, if your library is large enough, and you reclaim your tapes,
collocation does not buy you much, especially if you have tapes that =
mount
very quickly (that is, NOT DLT).

Just my $.02 worth...

Steve Roder, University at Buffalo
VM Systems Programmer
UNIX Systems Administrator (Solaris and AIX)
ADSM Administrator
(tkssteve AT buffalo DOT edu | (716)645-3564 |
http://ubvm.cc.buffalo.edu/~tkssteve)
<Prev in Thread] Current Thread [Next in Thread>
  • [no subject], Unknown <=