@a_p_
Andre - how do you define a thick provisioned vmdk ?
or what is an eager zeroed thick vmdk ?
In the end you have a large number of 1MB blocks eventually mixed with 512MB blocks and any of them is either
thin - means the block is allocated by a link to /dev/zero
lazy - means the block is allocated by a link to an offset on the vmfs-volume using the Z flag
eager - means the block is allocated by a link to an offset on the vmfs-volume.
Thin and lazy blocks turn into an eager block if the guest has written at least one bit to them.
Large blocks a 512 mb are also used but they do not change anything for this matter.
In the screenshot you see the first 3 large blocks a 512 MB of new blank vmdks.
First 2 examples are thin
Next 2 examples are lazy
Last 2 examples are eager
All 3 variants are first completely blank.
Then I wrote to the first MB and show the new allocation.
If you look carefully then you must conclude that only eager zeroed vmdks have a strict definition:
all blocks must use a reference to an offset without Z-flags.
As soon as you write to a thin vmdk it turns into a mixed thin/eager vmdk.
As soon as you write to a lazy vmdk it turns into a mixed lazy/eager vmdk
And also if you write to every MB-block of a thin or lazy vmdk - it will turn into an eager.vmdk.
Now lets look at some special cases: assume a GPT partitioned VMDK.
When the GPT-copy at the end of the disk is located in the last MB-block - then a user can write
to all locations: means a thin or lazy vmdk can after a while of use turn into a true eager.vmdk
When the GPT-copy goes into the third last MB-block - then user operations will typically not result in a true eager.vmdk.
Same thing with gaps between partitions ...
I assume that applications that require eager vmdks will use the strict definition: all blocks must be eager ... ,makes no sense otherwise.
So I think the question I asked : are there still any thin blocks ? is valid.
I guess that some applications keep their own extra information about a vmdk.
Like there is a vmsd-file for the use of secondary functions. And similar to the problems with vmsd-files I bet they have similar issues.
To see wether a snapshot-chain is valid - you need the complete chain of parentfilenamehints to be consistent.
In a similar way you can tell if a eager zeroed vmdk is really an eager zeroed.
And inflating a thin or lazy vmdk can produce a true eager vmdk - it just depends on how you do it
and if you make sure you also inflate the end of a vmdk or the gaps between partitions.
Anyway - a good secondary function or application should be able to check if it deals with true eager or mixed types.
________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...
