Hi Christian,
I’ve experienced the same issues on the FS9500. IBM mentioned that a fix might come in a future code update, but there’s no confirmed timeline yet.
Previously, I used to remove the replication policy from the replicated VG, remove the volume from the VG, increase its size, then add it back and reapply the policy. However, this approach forces a full resync of all volumes in that VG from scratch. Additionally, removing the replication policy causes data loss at the failover site, which can have significant implications for DR or QA environments using those disks.
With XIV, there was a useful "offline init" option that only synced the changes, thanks to change volumes holding the delta data. Unfortunately, that functionality isn’t available here.
I’m not sure which OS you are using, but for AIX and Linux, I now prefer to add another disk to the replicated VG and update the OS LVM accordingly. Within the policy-based replicated VG, I typically use disks of the same size and follow a consistent naming convention with a _n suffix. For example, in a DATAVG, I would standardize 256GiB disks and name them DATAVG_D1, DATAVG_D2, etc.
If you really need to increase the size of a particular disk, a better method is to add a new disk with the required size to the replicated VG, then migrate the old disk to the new one at the OS level. In AIX, you can use migratepv if the VG has multiple disks, and Linux has similar tools. Once migration is complete, you can remove the old disk and reclaim the space.
Hope this helps!
Thanks.