Scale out backup repository, synthetic fulls, force fast-clones to remain within same extent?

[HiHoItsOffToWorkWeGo]

Is there a way to force a synthetic full to perform a Fast Clone within the same extent of a scale-out repository, rather than doing a synthetic full to another extent?

Here's the problem I'm trying to solve:
Scale-out repository consisting of two extents:
rep1 50TB, with 5TB free. XFS
rep2 25TB, with 6TB free. XFS
Extent "rep1" contains a full backup of a 30TB VM, and thanks to fast-clone is able to contain multiple synthetic fulls of the VM thanks to the space efficiency savings offered by reflink technology on XFS.
The problem:
VEEAM has decided to use rep2 as the target of a synthetic full, but a full copy of the 30TB VM won't fit into the 6TB free space on rep2.
Is there a way to make VEEAM continue using the same extent and so perform a fast-clone only, when creating synthetic fulls?

[theviking84]

When you created your sobr did you use performance mode or data locality? It should be set to data locality to ensure chains stay on same extent.

[HiHoItsOffToWorkWeGo]

@theviking84 the SOBR is configured for data locality.

[foggy]

Hi Mark, I'd look at the reasons of why Veeam B&R is trying to create the new full on another extent - our support will be able to assist here. There's a chance the first extent doesn't have enough space according to Veeam B&R estimations.

[HiHoItsOffToWorkWeGo]

following up on foggy's comments: https://helpcenter.veeam.com/docs/backu ... ml?ver=100
updating the example to:
rep1 50TB, with 2.6TB free. XFS
rep2 25TB, with 6TB free. XFS
Extent "rep1" contains a full backup of a 30TB VM
The B&R "estimations" are that an incremental is going to be 10% the size of the VM.
Applying this to the updated example:
10% of 30TB is 3TB. Since extent "rep1" only has 2.6TB free, this forces B&R to place the incremental onto the "rep2" extent instead.
And this forces the next synthetic full to be made there as well, which fails because 6TB cannot contain 30TB.
This is a shame, really, since the actual size of the incremental was only around 240GB or so, and the original extent was very capable of containing another 10 of these.

[foggy]

So are you saying that some kind of an increment size estimation tweak would help in your case (provided that the size of increment is consistent)?