Snapshot – delta file doom!

There was a pretty decent argument happening at work the other day regarding how vmware handled snapshot files. We all knew and understood delta files were created on a hard disk basis and understood these delta files were the secret to the snapshot success.

Some people were convinced the delta files acted as a transaction log (similar to an SQL transaction log) that would capture and log any changes made to the base disk file. In this instance the delta file could grow without a limit – any number of changes could be applied to the base disk that would cause the delta ‘transaction log’ to be updated. If this were the case, the size of the delta file could easily exceed the size of the original vmdk.

This was the issue at question – I was adamant the delta file could not exceed the size of the vmdk that was being ‘snapped’. I can’t recall where I got this idea – but I was adamant. Must have been a hang over from the ESX 3.5 Fast track course I sat a while back.

I presented my case that the delta file was simply a block level copy of any changes that had been made – as in changes were made to the delta file instead of the base vmdk. Then when the snapshot was merged (deleted) these changes were just applied to the base vmdk. In this scenario – a delta can never exceed the size of the vmdk. As there is a finite amount of data defined.

Turned out to be an interesting conversation and I started to lose faith in my belief – so I did some googling around and found 2 decent articles:

This one provides some great information on how the delta file is created and written to. This cemented my ideas of how the delta works and I knew on the right track.

This one is less technical but answered the question none the less.

I’d recommend the first link for anyone that works with snapshots on a daily basis like we do – it really gives a good foundation to the underlying tech.

Comments are closed.