>I'm reposting the following message as I never saw it appear in the
digest
>version of ADSM-L when originally submitted on 8/24/99:
>
>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=3. 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=3, 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
|
