ASM has exactly same behaviour as with database files - ASM performs the rebalance on a per file basis till 11GR2.
The ASM metadata files (1-9) get rebalanced first. The ASM then rebalances the volume file 256, DRL file 257, and so on.
From this we see that the ASM rebalances volume files (and other ASM files), not the OS files in the associated file system(s).
So,probably ,it was moving extent related to that file from each disk ,so you would have seen this .
ACFS volumes are a separate feature of ASM to store non database files. ASM is not RAID and rebalancing is not on a disk but on a file basis. You can increase the rebalance power, but it can only do one I/O tread per file. As far as I understand, the ACFS volume is a single file from the ASM technical view and the rebalance operaton of the ACFS volume is on the basis of the ACFS volume file and not on the files stored inside it.
Yes, you right. But my question is, why ASM can't rebalance extents within volume files with multiply threads?
I'm not the developer of ASM and can only guess, but generally I would imagine it depends on the number of extends that need to be rebalanced. Similarly, a single process or single thread can only run on one CPU regardless of how many CPU's are in the system. So as far as I understand, multiple rebalance processes will not fight over a single file extend.