File cloning - why is first file clone a copy (but subsequent clones are not)?

[pmason]

If I run a manual clone in the same volume where there are a dozen or less .VMDk’s  the copy takes several minutes and says it's copying blocks – maybe I’m missing something, but it does seem to be a copy rather than a clone, see output below:

Create an initial clone:

clone start /vol/vol030102/200907071418020625410/wwdelme_test.vmdk /vol/vol030102/200907071418020625410/wwdelme2_test.vmdk -l

Volume capacity after clone – so it copies the blocks, but you can see dedupe savings also go up so it’s a fully deduped copy:

ldnengna03n01> df -s -g /vol/vol030102

Filesystem                used      saved       %saved

/vol/vol030102/          632GB      401GB          39%

This is what the clone status shows when the clone is running:

ID: 1

Source: /vol/vol030102/200907071418020625410/200907071418020625410_0-flat.vmdk

Destination: /vol/vol030102/200907071418020625410/wwdelme_test.vmdk

Block ranges:

State: running (71% done)

Total blocks: 5242880

Blocks copied: 1240849

Type: file

Why is copying taking place when the clone is within the same volume as the source VMDK? The only reason I can think of is that blocks in the VMDK representing free space are exceeding the 255 reference limit and new copies are being made – but that doesn’t explain why the initial clone of a VMDK should take so long and subsequent clones are quick. Any ideas or observations? Thanks.

[forgette · Accepted solution]

pmason wrote:
Why is copying taking place when the clone is within the same volume as the source VMDK? The only reason I can think of is that blocks in the VMDK representing free space are exceeding the 255 reference limit and new copies are being made – but that doesn’t explain why the initial clone of a VMDK should take so long and subsequent clones are quick. Any ideas or observations? Thanks.

You are spot on.  If dedup is enabled, the blocks in the source file are likely share across multiple files in the volume.  The reason subsequent clones are happening so quick is because you aren't hitting any blocks that require duplication.  As you clone more times, you may find that you end up duplicating other blocks.  Since this leads to indeterministic behavior, the Rapid Cloning Utility uses a controller based copy when it finds blocks at the reference limit.

Customers and partners (as well as employees) can take advantage of this functionality by using the API in RCU 3.0.  The API is documented in the appendix of the Rapid Cloning Utility 3.0 Installation and Administration Guide.  Also, please see TR-3742 for more information.  I hope this helps.

[pmason]

Thanks Eric,

much appreciated.

Peter