Found the answer which is as simple as: compression of the zfs-folder on the storage server.
I had (falsely) assumed storage-side compression/deduplication would be transparent from a vsphere perspective.
-> Question: is that the "normal" behavior also on other systems that support comp/dedup (somebody over at spiceworks-forum where i also posted this issue said storage-side space savings on his NetApp-Storage through comp/dedup weren't visible from vsphere).
Another reason for me to rule out compression was the huge differences in the sizes. Overall compression ratio on the Storage is 1,37 - compression ratio for the example-VM is 4,98. -> this brings me to the next (non vmware) question:
Used space on the virtual disk as displayed inside the VM is 2,1GB - the raw virtual disk file is 11,98 GB (uncompressed) -> free space (that did hold data and got deleted at some point) is roughly 9,8GB. These blocks do not contain zeros (since zeroing+punchzero on the vmdk eliminates the space almost completely) - still the compression ratio on this data is apparently insanly high. I'm wondering what kind of data is on the disk. Data is mostly static on this VM with only a tiny mysql-db that is generating IO.
-> Are there any tools that allow deeper analysis of freespace on an ext4-partition (like Zero/Non-Zero ratio)? Are there any tricks that could help in keeping the virtual disk files smaller without manually zeroing inside the VM and running vmkfstools on the vmdks?