Effective December 3, NetApp adopts Microsoft’s Business-to-Customer (B2C) identity management to simplify and provide secure access to NetApp resources.
For accounts that did not pre-register (prior to Dec 3), access to your NetApp data may take up to 1 hour as your legacy NSS ID is synchronized to the new B2C identity.
To learn more, read the FAQ and watch the video.
Need assistance? Complete this form and select “Registration Issue” as the Feedback Category.

VMware Solutions Discussions

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.

1 ACCEPTED SOLUTION

forgette

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.

View solution in original post

2 REPLIES 2

pmason

Thanks Eric,

much appreciated.

Peter

forgette

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.

View solution in original post

Announcements
NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner
Public