This script can not be used in version 7.3, which added automatic volume rebalance in the Storwize code. There is however a problem that volumes that have only a very short phases of high activity are classified correctly . These volumes must be found by analysis and re distribute manually.
I found this in the Aussie Storage Blog
Rebalancing of managed disk groups has to be done whenever you add new mdisks to a group - otherwise the IOPS and response
times on these managed disk groups become unbalanced and you will not see the expected performance out of the group.
SVC / Storwize Version 7.3 can automatically rebalance the workloads across the mdisks. If you have switched this on, this rebalance script should no longer be used.
It seems that the algorithm is checking the workload an all mdisks to build a candidate lists of Volumes to be redistributed. To become a rebalance candidate a disk must have a statistically high load.
We have seen the following. Disks which have high load for small time periods will probably never become a candidate for redistribution because their average usage is low. We have seen these disks struggling with performance because they have only be striped across some mdisks. We also have seen that the other volumes of this mdisk group run into problem because they stripe also across the mdisks with the high load. These unbalanced volumes have to be identified with an appropriate analysis and redistributed manually.
More informations about unbalanced mdisk groups here
Click on pictures to enlarge
in this picture you can see that most of the IO is handeled by only one managed disk.
It handles three times more IO than the other mdisks. This mdg will become a
performance problem soon when this one mdisk becomes more load and saturates.
This is how it is lookiong like in performance view. The green lines are IOPS from the
one mdisk and another with smaller load and thge red lines are the response times.
It is obvious that response time of the high load mdisk will become an issue soon.