Since 3.1.2.20 has a bug which prevents it from expiring some file, you
should move up to 3.1.2.40. Maybe as a side benefit, your problem will go
away. One other thought, when you installed 3.1.2.20, did you follow the
installation instructions reguarding doing an audit? Finally, IBM does not
respond to this list. If you want an official IBM answer, you need to open
a trouble ticket with them.
On Thu, 26 Aug 1999, Bob Brazner wrote:
> 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
>
|
