Drive C: holds spmetadata file
drive E: holds SPDATA file only target is sized to 300gb
drive G: is the iscsi target to spdate file on drive E. drive G: is partitioned to only used 110 gb. holds 4 2008r2 VM's, 3 are 15gb and the sps vm is 35gb.
a Few months back I notice something odd and that was that the SPDATA file grew larger then even what windows added all the vm files to be (110 gb spdata). after checking everything I decided to redo the iscsi target and monitor it. so I backed up the VMs and deleted the devices and spdate file and recreated a new spdata file (and chose deletion support). then copied the vms back in. initially every thing was fine it deduped the vms and the spadata file took up 33 gb of space. this made sense since 15 gb (for each vm) was already duplicate data anyway. at this point I started monitoring the size. and after a couple months the spdata file has grown from 33gb to 81gb of space! if I check the size within drive G its only taking 77 gb of space.
Now im confused because whats going on with the de-duplication, Now just incase you say "oh well it doesn't shrink to release data. it just zero out that data for later use" and all new writes for things like event logs , etc are what's making it grow. this wouldn't make to much sense since any use of dedupe for os vm use would just eventually grow bigger then the space actually being used adding no benefit to de-duplication. Especially since what you partition is all that Windows will use . if windows sees that the data takes up 100gb it is going to see it as full even if Starwind has 50gb of free zero'd out space to use. negating the need for dedupe in the first place since the spdata is going to keep growing to the size initially specified. I also included screen shot of the drive holding the spdata file and what windows see for the target.
- e spdata g iscsi target
- sws dedupe.JPG (79.87 KiB) Viewed 8392 times
