OK, so some theory...
If deduplication is implemented @ file system level (local or remote does not matter) then file system driver would just adjust amount of free space reported influenced by deduplication coefficient.
Say you have set of 10 files 1GB each but they are the same so actual used space would be 1GB (+ some metadata). File system would report ~9GB free and file parse utility would report 10GB used.
A little bit illogical and would break some apps (volume total space, free space and used space would not "play" with per-file used space) but OK.
If deduplication is implemented @ block level (below file system) so we'll hit a situation you describe. At some point volume of say 1TB with 1TB used can occupy say 10GB of a real disk space allocated
on a storage back end. Hard stop? No! You just need to re-provision the volume (apply "grow" function) and tell you have now say 2TB LUN. Both VMware vSphere and Microsoft Hyper-V can do it on-the-fly.
Bad news: some manual intervention is required. Good news: it's 100% transparent to file system and there are no weird numbers (volume free space Vs. others).
That's it
DavidMcKnight wrote:I think I`ll better explain how it works
That's what I was afraid of...
So can you explain to me why you would ever trust DeDup in a production environment?
If I had a DeDuped iSCSI volume that was holding a dozen windows 7 VMs that where all but identical (a computer lab for example). Even though I have to configure the iSCSI volume to be big enough to hold a dozen VMs (plus a little extra), the actual disk space being taken up on the datastore would be relatively small. Now lets say I have six of these volumes on my Starwind datastore. Because of DeDup I am massively over subscribed on the datastore, and if for some reason out side of my control, the data on the iSCSI volumes became less and less DeDupable. This starts to grow the size of the Starwind .IMG files (or what ever the new suffix is). This runs the D: Drive (where I store the .IMG files on my Starwind server) out of space. This would cause all sorts of hell.
I know this isn't Starwind's fault, nor VMware's. But the idea of DeDup and other types of compression on a networked datastore isn't that new of an idea. With out some way for a VMware host to talked to the datastore about compression (dedup or otherwise) it seems to me you are playing with explosives. At some point you're going to blow off your hand.