Thin disk file relation to internal virtual disk blocks?

[rickardnobel]

I have a question on how the file for a thin virtual disk correlates to the virtual disk that the guest operating system sees.

What I mean is this: for a thick disk I am assuming that when the Guest tries to read for example the first sector on the virtual disk, that information is located on the first sector inside the vmdk file that make up the disk. Since all the disk space already has been allocated for the file this would be natural. Can someone confirm that it is correct?

However, for a thin disk, what will happen if the writes are being done non-sequensial?

For example (on a totaly new drive) the guest operating system first writes to sector 1-10. This should mean that these sectors has to be instant zeroed and then the new information is written. If necessary the vmdk files is expanded too.

But, now assume that the guest operating system does write something to sector 100 000 000. Everything else is empty. Will the vmdk file expand up to this size or will it just be the size of the total amount of data of the disk (the exact size varied depending on the block size).

If the size of the thin vmdk file is just small, then is there some kind of lookup table for the internal relations of blocks that the guest sees and how the blocks are actually structured inside the thin disk? If so, is it know in which file this is?

[chadwickking]

<What I mean is this: for a thick disk I am assuming that when the Guest

tries to read for example the first sector on the virtual disk, that

information is located on the first sector inside the vmdk file that

make up the disk. Since all the disk space already has been allocated

for the file this would be natural. Can someone confirm that it is

correct?>

I would agree because the way VMFS handle fragmentation - it would do this to avoid it. Also, makes sense because most Disk act the same way.

<However, for a thin disk, what will happen if the writes are being done non-sequensial? >

To answer the rest of your questions I would find this white paper from vmware much more explanatory.

http://www.vmware.com/pdf/vsp_4_thinprov_perf.pdf

The versions of VMFS all use a 1MB block to avoid fragmentation so you shouldnt have hardly anthing like that

Not sure if this will answer all your questions -

Sounds like disk alignment may be sort of an issue - if you follow common best practices you shouldn't run into any of those types of problems. As far as the other questions regarding the architecture of thin vs. thick I really dont know.

http://communities.vmware.com/message/1263022

http://virtualgeek.typepad.com/virtual_geek/2009/04/thin-on-thin-where-should-you-do-thin-provisioni...

Cheers,

Chad King

VCP-410 | Server+

Twitter:

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

[rickardnobel]

Thank you for your reply. I think however I still do not know what I was after:

Assume we have a thin disk of 100 GB. The disk is empty. For some reason the operatingsystem writes something to the middle of the disk, just one sector with some random information at "position 50 GB". Will the disk vmdk file be the low default size of an almost empty disk, or will it grow to 50 GB?

[chadwickking]

No it will not. It looks at writes - "Zeroes and Ones" and those writes are placed at the beginning of the vmdk file. So your reporting should always be accurate. Hope this helps.

Cheers,

Chad King

VCP-410 | Server+

Twitter:

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

[rickardnobel]

No it will not. It looks at writes - "Zeroes and Ones" and those writes are placed at the beginning of the vmdk file.

Thanks for your reply!

So that means two things for me:

That the thin vmdk should not grow if not necessary, which is good.

That there could be internal fragmentation INSIDE the thin disk file, depending on how the guest operating file system driver places the data on the disk, and what the OS thinks is located on e.g. sector 1000 is perhaps not the 1000:nd sector inside the vmdk file. There must be some sort of translation file for this, is it known where that is located if so?

Also that would mean that there could be three layers of fragmentation for thin disks: 1. Internal logical fragmentation in the guest file system, e.g. NTFS. 2. Fragmentation between what the guest File system belives and how the data is actually located on the thin VMDK file. 3. Fragmentation of the physical vmdk-file over the VMFS datastore depending on how often it is expanded.

If that is correct it is impressive that there still is not much performance difference between thin and thick.

[a_p_]

Not knowing, just thinking of it.

There must be some sort of translation file for this, is it known where that is located if so?

If you think about shrinking a disk (filling unused blocks with zeroes and then sVMotion or clone it), only the "used" blocks are copied to the destination vmdk. If there wasn't a translation table, the shrink process would have to rearrange the NTFS.

Also that would mean that there could be three layers of fragmentation for thin disks: 1. Internal logical fragmentation in the guest file system, e.g. NTFS. 2. Fragmentation between what the guest File system belives and how the data is actually located on the thin VMDK file. 3. Fragmentation of the physical vmdk-file over the VMFS datastore depending on how often it is expanded.

If that is correct it is impressive that there still is not much performance difference between thin and thick.

I agree with you, that's actually a triple fragmentation. However, the block sizes used by VMware (1 MB) are way larger than in NTFS (4kb by default), so defragmentation will not be too much of an issue.

André

[rickardnobel]

Not knowing, just thinking of it.

Thanks for replying. Discussing things are very valuable even if we do not know the answers always,

>If there wasn't a translation table, the shrink process would have to rearrange the NTFS.

I did a experiment to try to prove this. I created a thin disk of 10 GB and inside it made four partitions of 2.5 GB each. I then started to copy things into the last partition, that is on the end of the disk, and the vmdk file grew, but only with the amount I copied. So there is not a 1-to-1 matching between the sectors that the virtual guest sees and what is in the thin disk file.

I then filled the other partitions in a somewhat random order and the disk file expanded, however there must be some sort of translation table to later find the data again. If I should guess I belive this table is at the beginning of the thin flat-vmdk itself.

Is there not a potential for worse read performance here? If a read request from the operating system first has to be looked up inside its own file system table, for example the Master File Table in NTFS, to find the sectors/clusters a certain file belongs too. Then this read request has to be interrupted by the vmkernel and remap it to the actual place in the thin disk file the clusters exists, and then this request has to be translated to the physical sectors on the VMFS datastore.

Or does it work any other way?