The disk pool doesn't become "unavailable", but rather the overflow causes a
lot of contention.

First, the migration will kick off - this will cause the pool to be
"draining" while you are filling it.  Lots of cross activity on the pool, not
to mention DB as updates are made.

Second, when you get to a point where there is not enough space left in the
pool to accept files that are being backed up - for example a large file that
exceeds the amount of free space - then the clients will try to allocate a
device in the next storage pool too - so they compete for hardware resources
with the migration process.  Again, not good.

The idea of a "landing pad" is a good one - it just needs to be big enough so
that YOU can control when the migrations occur, instead of Murphy.  :-)

Jerry Lawson


______________________________ Forward Header __________________________________
Subject: Advisibility of disk pools as "landing pads" only?
Author:  INTERNET.OWNERAD at SNADGATE
Date:    3/19/98 11:27 PM


Greetings, all.

I'm getting ready to define a set of disk storage volumes for my ADSM setup,
with the intent that I would be using them as a more-or-less "landing pad";
i.e. they can accept data more efficiently than the optical or tape, and I can
run more simultaneous sessions against them, but I don't really plan to keep
data on them for long:  my nightly incrementals might regularly exceed the
size of the disk pool.

Someone here noted today "but that might cause migration, which I would want
to avoid during the backup window".  Is there a reason to avoid that, _other_
than simply losing access to the migrating volume during the migration period?

Is this a dumb idea for some other reason?  I plan to have rather a lot of
fairly small spindles for disk pool: I won't lose a lot if a few of them go
into migration during a session, and I can migrate _all_ the data off
gradually during the day, so I can have a clean slate for the next night.

Any input, or references to Fine Manuals that I might Read, would be welcome.


-Allen S. Rout
=========================================================================