Snapshot space question

[Richard Siemers]

Returning back after I spoke to a pair of sales engineers about this. Their explanation was that the duplication avoidance only pertains to changed blocks being shared by multiple concurrent snapshots, they did not believe there is any attempt to dedupe or reuse existing blocks in the PIT area that match a newly changed block. I suspect that when Cleanur catches up on this thread he will clarify his position as well.

Building upon your example, this is what is meant by "non duplicative":

Monday evening snapshot = just metadata
Tuesday evening snapshot = just metadata
Wednesday evening snapshot = just metadata
Thursday working day the cell changes, old data copied to PiT area and ALL 3 snapshots updated to point to it and new data written to "live" VV.

[Cleanur]

Yes note the marketing reference it's more a play on words, non duplicative vs deduplication.

The snaps are non duplicative in that the de-duplication of data is across snaps within a tree not within the snapshot data itself. So if we have 30 snaps sharing a single block and that block is overwritten then a single block is written to Snapshot Data space and Snapshot Admin space is updated with pointers for the 30 snaps pointing to the new location. On some older systems this would result in 30+ backend writes. If we then overwrite another shared block with identical data to the above, then another block will be written to SD space and SA space modified accordingly.

So no de-duplication within the Snapshot Data space, but across the snapshot tree via Snapshot Admin space.

[slink]

Thanks for the clarifications. Good to learn how this stuff fits together.

P.S. Richard you don't look anything like yourself now you've changed your avatar