Spaceless GFS disk space usage on REFS

[chattingh]

A question for the ReFS guru's. Do spaceless GFS restore points on REFS "grow" over time? I'm referring to the actual disk usage, not the size as reported by the file system.

I understand that at the time of creation, they are comprised of pointers to blocks in the associated backup chain, so effectively take up zero, or close to zero space. But what happens as the associated backup chain cycles through its retention period, and blocks with a pointer to the spaceless GFS are removed from the backup chain?

To put it another way, lets say the GFS has a pointer to block "X" in the backup chain. The GFS consumes no space for that particular block. Over time block "X" is removed from the backup chain as it cycles through its retention period. Does that block then become associated with the GFS restore point; the GFS now consumes some disk space? And would it be a reasonable assumption that this GFS would continue to grow, the longer it was kept.

Am I thinking about this correctly?

I've gone over the animations showing the ReFS fast clone, but couldn't find one that illustrated this scenario.

Many thanks in advance.

Regards
Carl

[Mike Resseler]

Carl,

When Block X is referenced 2 times (or more) you indeed have the pointers meaning less space being used. However, let's say after a while Block X is only used once anymore, then you still have the space used for block X, but the second reference maybe became block Y so now there is more space usage. Makes sense?

In other words, while ReFS and the block cloning method can save on space, it is not something that you can calculate on that space will be saved all the time. So yes, if the backup chain is not needing the Block anymore, but the GFS does (as you state it), Block X won't be removed but remains there and uses obviously disk space.

Hope it is clear
Mike

[chattingh]

Thanks Mike, that does make sense.

Right now, its impossible to determine the actual space saving on individual files, we can only determine the space saving across an entire volume. Is there anyone at Veeam that is in the know with regards to what plans Microsoft may or may not have about adding this functionality? We're looking at this from a service provider perspective with respect to quantifying these savings.

[Mike Resseler]

Carl,

I'm not aware of any plans at MSFT for this. And honestly I doubt that it would be possible for them to calculate it upfront. But you never know

[chattingh]

OK, thanks for that.

Just thinking about determining the actual size of the GFS restore point some more, is it not perhaps something that Veeam could determine? As B&R creates or updates the GFS restore point, would it know how many, or what blocks are pointers to other .vbk/.vib/.vbr files vs how many blocks are not referenced from elsewhere, factor in the blocksize, and make an estimation of the actual underlying size? I realise it won't be 100% accurate due to the variable block size.

Bear in mind I know zilch about how this works under the Veeam hood!

[foggy]

Just thinking about determining the actual size of the GFS restore point some more

Carl, why, in the first place, do you need this information?

[chattingh]

@foggy, we are a Cloud Connect service provider, and we feel it would be nice to pass these space saving benefits on to the client. I do realise that not everyone feels the same way about this. I know there have been workarounds mentioned in the SP forum that allow one to work out the space saving for each tenant, but the complexity they bring is not for us.

At the end of the day its not critical, but more of a nice to have benefit.

Does that make sense?

[foggy]

Understood, makes sense.