To John Schneider et al,
Back on 6/23/99 I wrote the following:
"Our storage migration thresholds for our diskpool are set to 25 and 10 =
with
numpr=3D3. We do not use colocation. When migration (disk to tape) =
runs, the
process will start, process 1 small file, then finish with a completion
state
of success. Then, a few seconds later, another migration will process =
1
small
file and finish. And on ad infinitum. Sometimes a migration process =
will
actually do a bunch of files where bunch is a number like 20 or 50
comprising a
total of a whopping 1MB. We're on 3.1.2.20 on AIX 4.3.1, but we also =
saw
this
pattern on 3.1.1.5. This pattern of behavior is not consistent with my
reading
in the manual. Can anyone shed some light on this?"
I'd like to now add that our disk pool too, like John's, shoots up to =
99%
and
stays there due migration's inability to return the disk pool to the =
low
threshold. This of course causes other problems such as backups being
forced
to go to the next storage pool (tape), so now you get backups and =
migrations
competing for drives. Further, even though I have numpr=3D3, I usually =
only
see
one migration process fire up at a time.
John, it looks like our experience on AIX mirrors your Solaris =
situation.
Another reader said this is normal for cached systems. This is not =
correct.
Our system is cached and PCT UTIL (from QUERY STGPOOL) always shows =
numbers
in
the high 90's. But we don't care about PCT UTIL; our concern is =
ADSM's
failure to bring PCT MIGR back down to the low threshold. Another =
reader
suggested we time our migrations to occur after all backups are done. =
At
our
site, this is not practical. Our backups are taking place around the =
clock,
so
migrations need to be able to work around the clock. I also agree it =
would
be
nice if our disk storage pool was large enough to handle all our =
backups for
a
given day, but this too is not practical in our installation.
IBM, this migration behavior is strange to say the least, and =
disruptive to
operations to say the worst. Please comment.
Bob Brazner
|
