Re: Unload/Reload

If your drives are still balancing then something is amiss. You previously stated that disk I/O workload was exceptionally low on this system so I doubt that is the problem. Normally disk balancing of type *CAPACITY starts out a bit slow but completes within a single digit number of hours. You say CHKASPBAL still shows that balancing is active for ASP(1) Correct? How much memory and paging/faulting is there in the machine pool? Much work is done there for this function especially at the beginning of the balance work so starving that will have a very negative effect. In WRKDSKSTS you should see very lobsided numbers between the old and new disks with the old being very much higher on reads and the new guys high on writes. The new drives are usually much lower % busy at this point as they are just writing for now.

- Larry "DrFranken" Bolhuis


On 9/17/2012 7:19 AM, rob@xxxxxxxxx wrote:

Other than the potential catastrophic loss of data if your save turns out
to be worthless this is better than an unload/reload, why?

I would like to think that I could have performed an unload/reload faster.
Ok longer outage time. But a development lpar, done over a weekend,
could stand that. As it was I had to have two outages, one to remove the
raid striping, and then another IPL because the system wouldn't drop the
old disks from the configuration.

And I'd surely love to see these message disappear from CHKASPBAL
CPI18A3-Unit 15 is selected for end allocation.
But the way IBM explained it to me is that during a STRASPBAL it marks the
new drives as in this state to balance all new writes to the old drives
and not make the new disks "hot" by having all new writes pile up on these
drives only.

After how many days/weeks it takes to complete this balancing I plan on
doing a TRCASPBAL and then a STRASPBAL, this time with *USAGE instead of
*CAPACITY.

I realize that first sentence could be interpreted as "Other than that,
Mrs. Lincoln, how did you like the play?".


Rob Berendt