When a policy change is made from a RAID1 Mirroring policy to a Raid 5/6 policy the objects will have to be relayed out for this new policy change and vice versa. Transient capacity is generated when vSAN reconfigures objects for a policy change. But this can lead to a full cluster if to many objects are slated to be changed at once, especially if we're dealing with large objects.
For example you have the following policy's
RAID-6
this will take up 150% of the VMs allocated space
FTT2
this will take up 300%of the VMs allocated space
So If you are making a change on a VM that is 100 GBs on-disk. This VM will take up 300GBs using the FTT2 policy and once this VM has been moved to the Raid 6 policy it will consume 150GBs on disk. But during the change from the FTT2 policy to the Raid 6 policy this VM can use up to 450GBs on disk during the relay out of the components.
VMware by Broadcom recommends making storage policy changes in small batches to avoid potentially filling up the vSAN datastore during the relay out of the object components.
VMware vSAN
To prevent the cluster from potentially filling up and having space related issues apply the changes in small batches, keeping in mind VM/vmdk sizes, and validate you have the available free space on the vSAN datastore before making any changes.
If you do not have the space available to make the needed changes and you are moving to a policy that utilizes less space, then the current policy. Such as moving from RAID1 Mirroring policy to a RAID 5/6 policy. You can migrate the VM off of the vSAN datastore then back on using the new policy if you have alternative storage.
Another option if a RAID1 policy is in use is to change the policy to an FTT0/RAID0 policy removing the mirror copy to free up additional space.
Note: This is a last resort temporary option and a use at your own risk as you will no longer have any redundancy, and any failure could potentially result in data loss if the only active component resides on the disk/host failure.