Subscribe
Accepted Solution

Deduplication - a matter of perspective...?

Hi All,

I wondered if this question has already been answered. Apologies if it has...

The question is: From a by-the-book perspective, the implemetnation of Dedupe means that for a volume containing a cifs share, following dedupe being switched on and started, the free space goes up. this is visible from both the controller (eg: df) and the client system mounting the share (eg: Right click drive, click properties). Both views include the saved capacity.

Is there an easy way I can mask the savings away from the client so they see what they had before, while on the controller I see the free space (that I can thin provision into)?

For instance: If a client has 200GB as part of a service and fills up 150GB of it and then we dedupe it and the data footprint goes down to 100GB, that's fine, so then he puts another 120GB in over time, so his actual data size is over what he's paid me for, but it still uses, say 170GB (less than 200GB). From a service provider point of view, I'd like to have those savings in house, and not have them automatically visible to the client. This way I retain clarity with my customer base over what they have and have not used

Of course, in a LUN environmnet this happens anyway. Just wondered if there was a simple/obvious answer for a CiFS environment (options/qtrees? - sadly currently I have no time to get in the Lab to check this out)...

Thanks,

S

Re: Deduplication - a matter of perspective...?

I recommending basing a CIFS share off of a qtree.


Then apply a quota.


ASIS is volume based, for this reason I believe.

This is a great question though.  Would love to hear others input.

Re: Deduplication - a matter of perspective...?

Thks John, that's it