VMware Cloud Community
seamusobr1
Enthusiast
Enthusiast
Jump to solution

Reliable Sizing Statistics

Hi

Wonder if somebody could help

We have always used the disk policy sizing when placing VMs onto vSAN such as FT1 and Raid 5 which is 1.33 and FT1 and Raid 1 which is x2

What we would like to do is plan for future growth but what we have noticed over time is that the provisioned size on the VM is different from the object size which we have managed to extract using a script kindly provided by William Lam

We also realize that file deletions inside the VM do not reduce the object size and metadata overhead for vsan objects can increase the size.

Can anyone explain the difference that we are seeing here

0 Kudos
1 Solution

Accepted Solutions
TheBobkin
Champion
Champion
Jump to solution

Hello Seamus,

Good point, I should have said *may* reuse the space as it depends on the Guest-OS/filesystem which can of course vary widely.

Documented examples indeed imply NTFS (Windows2012R2) and that is also what I would have generally been using in homelabs, also Cormac points out the caveat with EXT4:

https://cormachogan.com/2017/11/02/guest-os-space-reuse-on-vsan/

I had a quick research into it and there are perhaps methods of zeroing only unallocated blocks but I haven't tested it so can't say whether it will apply in your case:

Ubuntu Manpage: zerofree — zero free blocks from ext2, ext3 and ext4 file-systems

Thus I would advise trying the above and/or having a deeper luck and/or asking a Linux-admin (if you are not one yourself).

Bob

View solution in original post

0 Kudos
3 Replies
TheBobkin
Champion
Champion
Jump to solution

Hello Seamus,

"we have noticed over time is that the provisioned size on the VM is different from the object size"

If you provision a 100GB vmdk (FTT=1,RAID1) and put 10GB of data on it, it will take up 20GB on disk not 200GB as vmdk are thin (Object Space Reservation=0) unless specified otherwise. Thus over time the capacity usage of vmdk data will grow as data is added at the Guest-OS level.

"We also realize that file deletions inside the VM do not reduce the object size and metadata overhead for vsan objects can increase the size."

Space reclaimation (TRIM/UNMAP) from deletions from Guest-OS level was only introduced in vSAN 6.7 U1 and also is not enabled by default - any version before this or on 6.7 U1 but not configured won't reclaim space. However it will use space freed up as opposed to growing the Object, e.g. if I create a 100GB vmdk, put 10GB of data on it, delete the 10GB of data and then add another 10GB it will re-use the space from the deleted 10GB of data.

Bob

seamusobr1
Enthusiast
Enthusiast
Jump to solution

Thanks Bob

That is what we seen but we have done some extensive tests on Ext4 and it does not seem to be very good at using blocks reclaimed from deletions it seems to prefer blocks that have not been used

Windows (later versions) does seem to better at doing this

0 Kudos
TheBobkin
Champion
Champion
Jump to solution

Hello Seamus,

Good point, I should have said *may* reuse the space as it depends on the Guest-OS/filesystem which can of course vary widely.

Documented examples indeed imply NTFS (Windows2012R2) and that is also what I would have generally been using in homelabs, also Cormac points out the caveat with EXT4:

https://cormachogan.com/2017/11/02/guest-os-space-reuse-on-vsan/

I had a quick research into it and there are perhaps methods of zeroing only unallocated blocks but I haven't tested it so can't say whether it will apply in your case:

Ubuntu Manpage: zerofree — zero free blocks from ext2, ext3 and ext4 file-systems

Thus I would advise trying the above and/or having a deeper luck and/or asking a Linux-admin (if you are not one yourself).

Bob

0 Kudos