There isn't a way to explicitly manage the performance data (bits) on the FSDB and control which data node it resides on.
DIsk rebalance works for adding new nodes, but won't ever make the disk distribution perfectly even.
On the global retention settings, that will age off old data, however it won't necessary keep this exactly scenario form happening again.
It would make sense that temp files (paks) threw a wrench in to the works, as you've got a pretty small disk space footprint right now. The most logical answer would be to add disk space and let the retention settings age off the slices of data.
vR Ops manages the data on the node itself, and if it gets too low on the FSDB partitions, it'll start to drop the data slices automatically. In your case though, you just didn't have enough space (in GB) to accomplish the upgrade since you have such a small overall footprint IMO.
*Also, note that depending on the upgrade path you did, some require more disk space than other. Upgrading to 6.2.* has some db upgrades in the mix, so it can require more than typical amounts of disk to succeed.
If you find this or any other answer useful please mark the answer as correct or helpful.
